Jumpstart network #918

JesseAbram · 2024-06-28T17:38:09Z

Jumpstarts the network with a global key

Uses same pathways but hardsets global key to 0x000 address

HCastano

There's a couple more things I need to look at, in particular the use of the zero-address around the different calls

pallets/registry/src/lib.rs

HCastano · 2024-07-09T16:24:50Z

pallets/registry/src/lib.rs

+        })]
+        pub fn jump_start_network(origin: OriginFor<T>) -> DispatchResult {
+            let _who = ensure_signed(origin)?;
+            let network_account = H256::zero();


We may want to avoid the zero address here because it has a well-known private key.

I say may instead of must since I don't have a full idea of where this address is actually "used", or if it's more of just a placeholder.

should be easily fixed with a guard on register, good find

pallets/registry/src/lib.rs

CHANGELOG.md

crates/threshold-signature-server/src/user/api.rs

Co-authored-by: Hernando Castano <HCastano@users.noreply.github.com>

ameba23 · 2024-07-10T07:25:42Z

Ive had a quick look at this and it looks great. Since it is a step towards having a network parent key but not fully implemented, Im trying to figure out what exactly the scope of this PR is.

This is what i am getting, please correct if wrong:

This adds a 'parent' DKG for the network - but does not yet remove per-user DKG.
The registry pallet tracks whether a network parent key exists (Done), does not exist (Ready) or DKG is in progress (InProgress), but there are not yet restrictions on users signing or registering when the network parent key does not exist.
The network DKG is activated by submitting a jump_start_network extrinsic - but there are currently no restrictions as to who can submit this or how big the network should be (Jump Start network requirements #923).
The network can only be jump started if it is either not yet jump started, or jump starting has been in-progress for at least 50 blocks.
The network is considered successfully jump started on getting register confirmations from all but one of the TSS nodes who participated in the network DKG (i am not totally clear on this, and i feel like it should be 100%).
Signature requests for the parent key account will result in an error.

@JesseAbram @HCastano

JesseAbram · 2024-07-10T15:06:08Z

Ive had a quick look at this and it looks great. Since it is a step towards having a network parent key but not fully implemented, Im trying to figure out what exactly the scope of this PR is.

This is what i am getting, please correct if wrong:

This adds a 'parent' DKG for the network - but does not yet remove per-user DKG.

yes

The registry pallet tracks whether a network parent key exists (Done), does not exist (Ready) or DKG is in progress (InProgress), but there are not yet restrictions on users signing or registering when the network parent key does not exist.

also yes because we don't use it yet.....and as we move the registery flow to the new flow this, is where having a block before jumpstart should be addressed

The network DKG is activated by submitting a jump_start_network extrinsic - but there are currently no restrictions as to who can submit this or how big the network should be (Jump Start network requirements #923).

The network can only be jump started if it is either not yet jump started, or jump starting has been in-progress for at least 50 blocks.

The network is considered successfully jump started on getting register confirmations from all but one of the TSS nodes who participated in the network DKG (i am not totally clear on this, and i feel like it should be 100%).

No it is all of them...... If you are referring to this line https://github.com/entropyxyz/entropy-core/pull/918/files#diff-1e0acd338c23affee5840b8efb06bd46be87c49819841bdcf3ce804631a40b92R340 it is because the last confirmation sets it to done as if there were 4 out of 5 done, this one is the 5th

Signature requests for the parent key account will result in an error.

@JesseAbram @HCastano

HCastano

Getting close!

Couple things:

It's unclear to me why we need to substitute the parent verifying key in the KVDB with 0x00...
I'm still slightly worried about the use of the zero address here, but we could kick this down the road to at least get things moving (maybe we open an issue for right now)
We need to rename comments, errors, etc. to parent

crates/threshold-signature-server/src/user/api.rs

crates/threshold-signature-server/src/user/errors.rs

pallets/registry/src/lib.rs

crates/threshold-signature-server/src/user/tests.rs

HCastano · 2024-07-10T16:34:14Z

pallets/registry/src/lib.rs

+            ensure!(
+                encoded_sig_req_account != NETWORK_PARENT_KEY.encode(),
+                Error::<T>::NoRegisteringFromParentKey
+            );


I think this could be useful to have. E.g we can have the Entropy network control an account on other chains like this.

Obvs this wouldn't work if the parent key address is the zero-address though.

crates/threshold-signature-server/src/user/api.rs

Co-authored-by: Hernando Castano <HCastano@users.noreply.github.com>

JesseAbram · 2024-07-10T17:05:10Z

Getting close!

Couple things:

It's unclear to me why we need to substitute the parent verifying key in the KVDB with 0x00...

In theory we don't and we can change it, but when we keep it a set amount, we can and it is easier to make it a global constant and have if parent key do x code easier (which we can also add extra security on it too)

I'm still slightly worried about the use of the zero address here, but we could kick this down the road to at least get things moving (maybe we open an issue for right now)

Global constant, I know your impulse, I think it is fine we can make it any random key tbh

We need to rename comments, errors, etc. to parent

HCastano

Few things we need to follow up on, but looks good otherwise!

crates/threshold-signature-server/src/user/errors.rs

HCastano · 2024-07-11T20:32:55Z

crates/threshold-signature-server/src/user/api.rs

            data.block_number,
        )
        .await?;
        let verifying_key = key_share.verifying_key().to_encoded_point(true).as_bytes().to_vec();
-        let string_verifying_key = hex::encode(verifying_key.clone()).to_string();
+        let string_verifying_key = if sig_request_account == NETWORK_PARENT_KEY.encode() {
+            hex::encode(*NETWORK_PARENT_KEY)


One suggestion: instead of overwriting the parent's verifying key to be 0x00 we could
have a separate "forbidden key" entry, PARENT_VERIFYING_KEY, which points to the parent
verifying key.

For those checks you mention, we could achieve them the same way, but doing an extra
lookup.

That way we keep the verifying key entries consistent.

sure at this point tho im in favour of opening an issue

Yeah an issue is fine

CHANGELOG.md

Co-authored-by: Hernando Castano <HCastano@users.noreply.github.com>

…start-network

JesseAbram added 12 commits June 28, 2024 13:37

Jumpstart network

2ea8b13

some tests

596b50f

add confirmation check

0518683

fix jump start details test

c2fbb1e

test jump start

88478a5

jump start threshold side test

b11c139

jumpstart test

063e9cd

test master key sign

18ccbff

fmt

7e75fb2

fmt

a1d690b

add benchmarks to register

1c27b58

clean

5b2d3d4

JesseAbram marked this pull request as ready for review July 2, 2024 19:52

JesseAbram requested a review from HCastano July 2, 2024 19:52

JesseAbram self-assigned this Jul 2, 2024

changelog

517109e

JesseAbram mentioned this pull request Jul 5, 2024

Jump Start network requirements #923

Open

clean

e236be6

HCastano reviewed Jul 9, 2024

View reviewed changes

Apply suggestions from code review

1600811

Co-authored-by: Hernando Castano <HCastano@users.noreply.github.com>

JesseAbram added the Bump `transaction_version` A change which affects how existing extrinsics are created (e.g parameter changes) label Jul 9, 2024

JesseAbram mentioned this pull request Jul 9, 2024

Jump Start Network Confirm Requirements #927

Open

JesseAbram added 3 commits July 9, 2024 16:13

fixes

7c77aea

add comment

879cba6

fix

84c1770

JesseAbram requested a review from HCastano July 9, 2024 22:03

HCastano reviewed Jul 10, 2024

View reviewed changes

Apply suggestions from code review

8c7338d

Co-authored-by: Hernando Castano <HCastano@users.noreply.github.com>

fix

237078b

change master to parent

0466073

JesseAbram requested a review from HCastano July 10, 2024 17:12

HCastano added this to the t-of-N Redesign milestone Jul 11, 2024

JesseAbram added 3 commits July 11, 2024 14:06

fix build

f726f51

fix build

5fcacb0

fix

8917d32

HCastano approved these changes Jul 11, 2024

View reviewed changes

JesseAbram and others added 3 commits July 11, 2024 13:45

Update crates/threshold-signature-server/src/user/errors.rs

cc7e7de

Co-authored-by: Hernando Castano <HCastano@users.noreply.github.com>

fix

1ec04d7

Merge branch 'master' of github.com:entropyxyz/entropy-core into jump…

4d8fb55

…start-network

JesseAbram mentioned this pull request Jul 11, 2024

Parent Key Value #931

Closed

JesseAbram merged commit 314849f into master Jul 11, 2024
13 checks passed

JesseAbram deleted the jumpstart-network branch July 11, 2024 21:41

JesseAbram mentioned this pull request Jul 15, 2024

Create pathway for a global key DKG #877

Closed

This was referenced Aug 2, 2024

New on-chain registration flow #955

Merged

Allow registration from NETWORK_PARENT_KEY #983

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Jumpstart network #918

Jumpstart network #918

JesseAbram commented Jun 28, 2024

HCastano left a comment

HCastano Jul 9, 2024

JesseAbram Jul 9, 2024

ameba23 commented Jul 10, 2024

JesseAbram commented Jul 10, 2024

HCastano left a comment

HCastano Jul 10, 2024

JesseAbram commented Jul 10, 2024

HCastano left a comment

HCastano Jul 11, 2024

JesseAbram Jul 11, 2024

HCastano Jul 11, 2024

JesseAbram Jul 11, 2024

Jumpstart network #918

Jumpstart network #918

Conversation

JesseAbram commented Jun 28, 2024

HCastano left a comment

Choose a reason for hiding this comment

HCastano Jul 9, 2024

Choose a reason for hiding this comment

JesseAbram Jul 9, 2024

Choose a reason for hiding this comment

ameba23 commented Jul 10, 2024

JesseAbram commented Jul 10, 2024

HCastano left a comment

Choose a reason for hiding this comment

HCastano Jul 10, 2024

Choose a reason for hiding this comment

JesseAbram commented Jul 10, 2024

HCastano left a comment

Choose a reason for hiding this comment

HCastano Jul 11, 2024

Choose a reason for hiding this comment

JesseAbram Jul 11, 2024

Choose a reason for hiding this comment

HCastano Jul 11, 2024

Choose a reason for hiding this comment

JesseAbram Jul 11, 2024

Choose a reason for hiding this comment