veramolabs / did-eth Goto Github PK

We should offer a web3 dApp like ENS does which can be used to anchor stuff and change everything on my wallet's dids.

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Rate-Limited

These updates are currently rate-limited. Click on a checkbox below to force their creation now.

• chore(deps): update dependency @typechain/ethers-v5 to v10.2.0
• chore(deps): update dependency @types/node to v18.15.11
• chore(deps): update dependency eslint to v8.37.0
• chore(deps): update dependency eslint to v8.37.0
• chore(deps): update dependency eslint-config-prettier to v8.8.0
• chore(deps): update dependency eslint-config-prettier to v8.8.0
• chore(deps): update dependency eslint-plugin-import to v2.27.5
• chore(deps): update dependency eslint-plugin-jest to v27.2.1
• chore(deps): update dependency eslint-plugin-n to v15.7.0
• chore(deps): update dependency eslint-plugin-promise to v6.1.1
• chore(deps): update dependency ethers to v5.7.2
• chore(deps): update dependency ganache to v7.7.7
• chore(deps): update dependency hardhat to v2.13.0
• chore(deps): update dependency prettier to v2.8.7
• chore(deps): update dependency prettier to v2.8.7
• chore(deps): update dependency prettier-plugin-solidity to v1.1.3
• chore(deps): update dependency solhint to v3.4.1
• chore(deps): update dependency solidity-coverage to ^0.8.0
• chore(deps): update dependency ts-node to v10.9.1
• chore(deps): update dependency typescript to v4.9.5
• chore(deps): update dependency typescript to v4.9.5
• chore(deps): update dependency uint8arrays to v3.1.1
• chore(deps): update jest monorepo (@types/jest, babel-jest, jest)
• chore(deps): update typescript-eslint monorepo to v5.57.0 (@typescript-eslint/eslint-plugin, @typescript-eslint/parser)
• fix(deps): update dependency @ethersproject/abi to v5.7.0
• fix(deps): update dependency @ethersproject/abstract-signer to v5.7.0
• fix(deps): update dependency @ethersproject/address to v5.7.0
• fix(deps): update dependency @ethersproject/basex to v5.7.0
• fix(deps): update dependency @ethersproject/contracts to v5.7.0
• fix(deps): update dependency @ethersproject/keccak256 to v5.7.0
• fix(deps): update dependency @ethersproject/providers to v5.7.2
• fix(deps): update dependency @ethersproject/signing-key to v5.7.0
• fix(deps): update dependency @ethersproject/transactions to v5.7.0
• fix(deps): update dependency did-jwt to v6.11.5
• fix(deps): update dependency did-resolver to v4.1.0
• chore(deps): update dependency @types/mocha to v10
• chore(deps): update dependency babel-jest to v29
• chore(deps): update dependency ethereum-waffle to v4
• chore(deps): update dependency ethers to v6
• chore(deps): update dependency semantic-release to v21
• chore(deps): update dependency typescript to v5
• chore(deps): update dependency uint8arrays to v4
• 🔐 Create all rate-limited PRs at once 🔐

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• chore(deps): update semantic-release monorepo (@semantic-release/changelog, semantic-release)
• chore(deps): update babel monorepo (@babel/core, @babel/preset-env, @babel/preset-typescript)

Ignored or Blocked

These are blocked by an existing closed PR and will not be recreated unless you click a checkbox below.

• chore(deps): update dependency @nomiclabs/hardhat-etherscan to v3.1.7
• chore(deps): update dependency @nomiclabs/hardhat-waffle to v2.0.5
• chore(deps): update dependency @typechain/hardhat to v6.1.5
• chore(deps): update dependency chai to v4.3.7 (chai, @types/chai)
• chore(deps): update dependency dotenv to v16.0.3
• chore(deps): update dependency hardhat-gas-reporter to v1.0.9
• chore(deps): update dependency typechain to v8.1.1
• chore(deps): update dependency @nomiclabs/hardhat-ethers to v2.2.2

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

The existing DID:Ethr Method Specific Identifier specification is here

In order to support a multichain world I suggest the following for the DID:Eth identifier syntax:

1. did:eth followed by a CAIP-10 address. For EVM networks EIP155+ChainID would most likely be the dominant address type used. This follows the DID:PKH Identifer scheme as seen here
   Some examples:

• Ethereum: did:eth:eip155:1:0xb9c5714089478a327f09197987f16f9e5d936e8a
• Polygon: did:eth:eip155:137:0x4e90e8a8191c1c23a24a598c3ab4fb47ce926ff5
• Hedera: did:eth:eip155:296:0xa0ae58da58dfa46fa55c3b86545e7065f90ff011

2. We do not support a "default" scheme if a CAIP-10 address is not properly specified (DID:Ethr supported a default to Ethereum mainnet).

3. We do not support other address types not supported by CAIP10

Feedback appreciated.

Contract methods that update the DID document should also have a flag (or a variant) that also stores the attributes in contract storage, besides emitting the event.

This would be useful for partial on-chain resolution.

We also need to be mindful of revocation of attributes as these would have to also revoke the potentially stored data, regardless of the flag.

We should move away from the proprietary way of doing meta transactions in 'did:ethr' by using a public standard.

EIP-712 would allow a good human readable way of doing that. I see value in doing that human readability especially if we consider a dApp to manage your DID in the future (think ens dApp) with the extended feature of letting some entity do a direct FIAT conversion feature by leveraging meta transactions ("let our payment wallet handle your transaction and pay us 5$"). Then a user could finally really see what their wallet is signing to cross check it instead of blindly signing a hash string.

Is there some alternative to EIP-712?

The identity "owner" concept used by the DIDRegistry contract doesn't match the "controller" concept from DID core spec. We have to make this distinction more clear in the spec as it has caused confusion in the past.

To support the "controller" property, the DID Attributes should be used.

As discussed in the channel we would like to perhaps provide an option for users to separate the keys from the identifiers. This would be relevant to both Polygon ID and Hedera as we natively provide the ability to separate the keys from the identifiers. It would also allow for future key rotation features.

This would not be something v1 of did-eth it would probably be more for a v2, just want to put it on the roadmap for the future.

@Reccetech please feel free to add comments.

A standardized contract interface will enable an implementation of proxy upgradability.

A contract interface provides the following benefits:

1. Provides guarantees to implementors about the underlying api and implementation of a contract they are using
2. The interface guarantees interoperability across contract versions so that upgradability is more seamless
3. Interfaces support modularity by defining the specific calls that must be part of a particular contract
4. Standardization and transparency are also introduced by a clean interface implementation
5. As mentioned above the interface will enable us to implement an upgradeable proxy contract with minimum dependencies
6. Interfaces may also promote security by reducing the attack surface of individual contract implementations

decentralized-identity/ethr-did-resolver#110

Provide a Dockerfile which may be used for containerized development across all platforms and architectures. Key benefits will include:

Consistency: Development containers ensure that everyone on the team is using the same environment, reducing "works on my machine" issues.

Isolation: Containers provide isolation from the host system, preventing conflicts between different software versions.

Reproducibility: Containers can be versioned, making it easy to replicate the exact development environment in different stages of the project.

Portability: Development containers can be shared and run on different machines, making it easier to onboard new team members or work across multiple devices.

Dependency Management: Containers encapsulate dependencies, eliminating the need to install and manage them directly on the host system.

Requirements

1. support foundry and hardhat workflows
2. require linter
3. require prettier
4. ensure prettier for solidity files as well
5. ensure solidity formatting is consistent with common solidity conventions

UUPS is the best approach for introducing contract upgradability. UUPS offers several key benefits:

1. UUPS offers a simplified model versus previous proxy standards
2. UUPS is secure because the logic itself authorizes its own upgrade. This is an advantage over having an external proxy responsible for upgrade authoririty.
3. A clean implementation of UUPS is already provided by OpenZeppelin and will minimize the impact and change required for this project
4. UUPS is more flexible for the storage layout than other proxies. This improves the long term maintainability for the contract.
5. UUPS is gas efficient
6. UUPS is transparent to the user
7. UUPS is the trusted and preferred approach to proxy contracts
8. Deployment of the logic contract may cost less gas than a full contract deployment

Don’t want to crowd the other issue with Diamonds talk.

https://eips.ethereum.org/EIPS/eip-2535

What I mean by Diamonds magic is that it’s possible to let anyone add a resolver module to the contract. You call a function in the contract with EVM byte code for the resolver logic, which is then registered with an identifier from a hash of the byte code.

Using the hash is important as the identifier will be the same across all deployments for the same resolver logic.

You can then use the hash identifier when interacting with your DIDs.

What remains is how to tie the resolver to a string like “did:eth”. This can be gated by governance.

It would then become possible to upgrade the did method while the previous version(s) remain available. You add a new resolver module, and point the method string at the new one.

There are a lot of details I’ve left out. Security and gas implications are the big questions.

Then did:keri isn’t a competitor, but can be used within our contract.

Originally posted by @Hmac512 in #2 (comment)

We should have a central place for building & deploying our smart contracts to minimize errors due to a variable environment (local machine). I've used Truffle in the past, but I heard hardhat is the better option. Deployments to mainnet or other non-dev networks should then be secured by our governance framework. I know this can be achieved by using Gnosis Safe as a provider in Truffle. Does this work with hardhat also?

Does anyone have experience how other DAOs solve this problem?

Solidity based testing is an important innovation in contract development.

Solidity based testing with EVM emulation promotes:

1. Developer familiarity with the Solidity language and the EVM behavior and characteristics. This familiarity improves meaningfulness and effectiveness of tests and offers such benefits such as time based tests and fuzzing.
2. Seamless integration – Solidity tests directly access target contract code and support code without any wrapper or connectivity code
3. Code reuse – Solidity code may be reused across test and production infrastructure promoting software best paractices and reducing duplication of effort and logic. This means that Solidity tests will be easier to maintain over time
4. Debugging – debugging solidity tests is more straightforward. The same toolset used for build and deployment and simplifies the process of identifying and fixing issues
5. Consistency – Test and coding style conventions can follow the same norms and improve readability and maintainability. Developers don't need to switch to or even learn alternative languages in order to develop contract code
6. Test execution performance with Foundry and Rust
7. Refactoring benefits – refactoring is easier and safer when tests and contracts are part of a parallel implementation
8. community – the solidity community will be able to read, understand, support and contribute to our tests

All the "Signed" methods take V, R, S params, but it might be wiser to replace them with a more opaque bytes param for the signature, as that would open up the possibility of using more than just secp256k1 signatures

This would also be a prerequisite for #48

Continuous integration will help us develop to a standard while preventing commonplace errors

Requirements:

1. full lint required
2. prettier check required
3. test build required to pass

The compelling reasons to adopt CI:

1. Frequent Integration: CI promotes frequent integration, making this process smoother and less error-prone.

2. Fast Feedback: Whenever developers push code, the CI system runs automated tests. If there's a problem, developers get immediate feedback and can fix the issue while the context is still fresh in their minds.

3. Higher Quality Code: With CI, there's an emphasis on writing automated tests. This encourages better code quality and ensures that existing functionalities are not broken by new changes.

4. Reduced Manual Testing: Automated tests in CI mean less time is spent on repetitive manual tests, freeing up time for other tasks and reducing human-induced errors.

5. Consistency: CI processes ensure that the same steps are followed for every code integration, guaranteeing that code is consistently built and tested.

6. Documentation: The CI system automatically documents each build process (which changes were integrated, test results, etc.), providing a clear history of the project.

7. Early Bug Detection: Catching bugs early in the development process is generally more cost-effective than fixing them later in production.

8. Efficient Collaboration: In large teams or distributed teams, CI ensures that code from different developers is consistently integrated and tested, reducing the chances of conflicting changes.

9. Delivery Speed: Since integration issues are found and fixed continuously, the software is always in a releasable state. This can lead to faster delivery cycles.

10. Environment Replication: CI systems can be configured to replicate the production environment. This ensures that the software is being built and tested in an environment similar to where it'll be deployed.

11. Enhanced Developer Confidence: Knowing that changes are automatically tested upon push boosts developer confidence. They can be more assured that their changes won't unintentionally break the application.

12. Cost Savings: Although setting up CI requires some upfront investment, it can lead to significant savings in the long run by reducing the time spent on manual testing, bug fixes, and troubleshooting.

13. Integration with Other Tools: Modern CI systems can be integrated with various tools for code quality checking, performance testing, deployment, etc., providing a streamlined end-to-end process.

14. Scaling: As your team grows, the CI process can handle the increased load without much change, ensuring consistent integration even with more developers and more frequent code pushes.