Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add partial deposits support to charon dkg command #2889

Closed
3 tasks done
xenowits opened this issue Feb 19, 2024 · 0 comments
Closed
3 tasks done

Add partial deposits support to charon dkg command #2889

xenowits opened this issue Feb 19, 2024 · 0 comments
Assignees
Labels
protocol Protocol Team tickets V1

Comments

@xenowits
Copy link
Contributor

xenowits commented Feb 19, 2024

🎯 Problem to be solved

Add partial deposits support to dkg command. This enables users to create a new cluster definition v1.8 that supports partial deposits.

🛠️ Proposed solution

Add partial deposits support to the charon dkg command.

🧪 Tests

  • Tested by new automated unit/integration/smoke tests
  • Manually tested on core team/canary/test clusters
  • Manually tested on local compose simnet
@github-actions github-actions bot added the protocol Protocol Team tickets label Feb 19, 2024
@boulder225 boulder225 added the V1 label Feb 21, 2024
obol-bulldozer bot pushed a commit that referenced this issue Feb 27, 2024
* `dkg` command supporting partial deposits (previous work added cli option `--deposit-amounts` to `create dkg` command).

One important and _not very elegant_ change was done to the `exchanger` component, specifically:
```
	// sigDepositData is responsible for deposit data signed partial signatures exchange and aggregation.
	// For partial deposits, it increments the number for each unique partial amount, e.g. 201, 202, etc.
	sigDepositData sigType = 200
```

This is because we need to execute several rounds for each partial deposit amount and we need to distinguish between each such round and store them independently (parsigdb). To make it more elegant, a drastic change to the protocol would be required, such as adding additional field to the tuple of {Duty, Slot}, I would call it a group. But when I tried to go this route, I quickly realized the viral effect of this change and too many components will be affected. Hence the simplification and the present solution. Open to discuss alternative options.

category: feature
ticket: #2889
@pinebit pinebit closed this as completed Feb 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
protocol Protocol Team tickets V1
Projects
None yet
Development

No branches or pull requests

3 participants