summa-dev/eip-draft

eip-draft's Issues

Solidity Interface for submitProofOfSolvency Function

In the submitProofOfSolvency function, the event that should be emitted upon successful submission should probably be SolvencyProofSubmitted or ProofOfSolvencySubmitted instead of AddressOwnershipProofSubmitted. Otherwise, maybe the function name should be changed to reference address ownership.

Core Circuits and Data Structures

We might want to elaborate a bit more on how the "Proof of Inclusion Circuit" and "Proof of Solvency Circuit" work, and how the "Liability Tree" data structure is structured and utilized.

Rename Proof of Exchange Solvency to Proof of Solvency (for exchanges)?

I don't know why I didn't catch this earlier, but I think it's more intuitive to call it "Proof of Solvency (for exchanges" than "Proof of Exchange Solvency".

Thoughts?

Motivation and Rationale needs to be fleshed out

The Motivation and Rationale sections currently only contain a couple of sentences each. These sections are crucial because they "sandwich" the Specification section, providing the necessary context and reasoning.

• The Motivation acts as the problem statement, helping everyone understand what we're trying to solve.
• The Rationale explains why the proposed spec is the right way to solve that problem.

To make this EIP as clear and compelling as possible, we need to flesh out these sections more thoroughly.

Here are some ways to flesh them out (according to ChatGPT):

Motivation Section:

1. Background: Briefly outline the issue's history or relevance.
2. Examples: Cite specific cases where the problem exists.
3. Impact: State who's affected by the issue.
4. Goals: List what the EIP aims to achieve.

Rationale Section:

1. Alternatives: Mention other solutions considered and why they're not chosen.
2. Tech Justification: Give technical reasons for the chosen solution.
3. Feedback: Summarize community input and its impact on the EIP.
4. Vision: Explain how the EIP fits into broader goals.

Security Considerations

Might need to fill this section out a bit more:

• Detail potential risks and mitigation strategies concerning ZK proofs implementation.
• Address security implications of off-chain verification.
• Discuss error handling and potential exploitation by malicious actors.
• Address dependency security and potential reentrancy attacks.

Add link to Ethereum Magicians discussion

Here's the posted discussion: https://ethereum-magicians.org/t/eip-draft-proof-of-solvency-standard-for-centralized-exchanges/15963

According to EIP-1, we are to include a discussions-to header in the preamble like so:

discussions-to: https://ethereum-magicians.org/t/eip-draft-proof-of-solvency-standard-for-centralized-exchanges/15963

TODOs before Submitting as an EIP

TODOs as of 2023-10-19:

1. Authorship Clarification: Discuss and decide who should be listed as authors based on their contributions.
2. Core Circuits Expansion: Provide more details on the core circuits within the Specification section.
3. Test Cases Addition:
   • Include tests for function inputs, both valid and invalid.
   • Test event emissions for correctness.
   • Test the ZK proof verification functionality.
4. Security Considerations Expansion:
   • Detail potential risks and mitigation strategies concerning ZK proofs implementation.
   • Address security implications of off-chain verification.
   • Discuss error handling and potential exploitation by malicious actors.
   • Address dependency security and potential reentrancy attacks.
5. Placeholder Text Removal: Replace or remove all placeholder text throughout the document.
6. Community Engagement: Engage with the community on the provided discussion link to gather feedback.
7. Final Compliance Review: Conduct a final review to ensure the document complies with EIP-1 guidelines.

Initial Steps (for reference)

According to the official README of the EIPs repo, we need to do the following:

• Discuss the idea on Ethereum Magicians.
• Read over EIP-1 for instructions on creating an EIP.
• Create a draft with the necessary headings.
• Fill out each section.
• Get feedback, and iterate.

Let's also keep this in mind:

It is highly recommended that a single EIP contain a single key proposal or new idea. The more focused the EIP, the more successful it tends to be.