[stacks-core] Update .pox-4 to properly handle stacker's signing key registration

[jferrant]

All stacking registration functions within pox-4 must include a public key to be used for signing messages. This public key is also used to determine the stacker-db configuration of the signers' stacker-db instance.

This ticket can be broken into 3 tasks:

• [stacks-core] Update .pox-4 stacker registration functions to include a signer key #4057
• [stacks-core] Update .pox-4 to calculate signer key vote shares #4059
• [stacks-core] Update the stacker-db contract from the list of registered signers #4058
• [stacks-core] Update .pox-4 for signer-set getter & setter #4147

Context:

Signers need to be able to query the node for the following up to date info:

signers = [
            {public_key = "swBaKxfzs4pQne7spxhrkF6AtB34WEcreAkJ8mPcqx3t", key_ids = [1, 2, 3]}
        ,
            {public_key = "yDJhntuJczbss1XGDmyWtG9Wpw5NDqoBBnedxmyhKiFN", key_ids = [4, 5, 6, 7, 8]}
        ,
            {public_key = "xNVCph6zd7HLLJcuwrWz1gNbFoPHjXxn7cyRvvTYhP3U", key_ids = [9, 10]}
        ,
            {public_key = "p2wFfLEbwGCmxCR5eGa46Ct6i3BVjFrvBixRn7FnCQjA", key_ids = [11, 12, 13, 14, 15, 16]}
        ,
            {public_key = "26jpUNnJPvzDJRJg3hfBn5s5MR4eQ4LLTokjrSDzByh4i", key_ids = [17, 18, 19, 20]}
        ]

As long as there is a list of public keys mapped to vote shares that is consistent between calls, should work

NOTE: reward_slots == vote_shares == key_ids (each key id represents ONE vote sh

[saralab]

@jferrant TO breakdown these into tasks and we'll revisit the estimations

[jferrant]

As signers' keys are registered via stack-stx and similar calls, the node can read these registered signers' from the pox contract at T-99th block of Reward cycle T. It can then calculate the vote shares associated with each signing key and in turn should update the contract state via a call to some function similar to "register-signer-set(list(tuple(buff [33], list(4000 u32))" where the list is of a tuple of full public key to a list of key ids (the vote shares). There is at most 4000 signers. Also each signer has at most 4000 vote shares (if one signer...then it will own 4000 vote shares).

[setzeus]

My understanding from the above & the current state of the Clarity/PoX-4 gdoc is that we're currently missing a getter & setter for the "currently-registered-signers" & "previously-registered-signers."

Opening an issue accordingly.

[setzeus]

Actually, following up here, reviewing the Clarity/Pox-4 design doc we actually did mention having a 'reward-cycle-pox-signer-list' map but we ended up removing it.

@jcnelson can you confirm whether we do or don't need list of signing keys (mapped to signer IDs) for the current & previous cycle stored in PoX-4?

[setzeus]

Working on a draft for setting & getting signer-set in #4147 & I believe I'm running into run-cost limits while creating the data structure.

Per the requirements above I decided on the following data-var with an accompanying 'getter' that works with 'at-block' to return the signer-set for a particular cycle; these reqs call for '4000 signers each with at most 4000 shares:'

(define-data-var current-signer-set (list 4000 {signing-key: (buff 33), key-ids: (list 4000 uint)}) (list ))

The above however returns the following error message when I run the 'pox_4_instantiates' test:

"INFO [1702383361.960986] [stackslib/src/chainstate/stacks/index/file.rs:191] [chainstate::stacks::boot::contract_tests::pox_4_instantiates] Preemptively vacuuming the database file to free up space after copying trie blobs to a separate file
thread 'chainstate::stacks::boot::contract_tests::pox_4_instantiates' panicked at stackslib/src/chainstate/stacks/boot/contract_tests.rs:585:10:
called Result::unwrap() on an Err value: Unchecked(ValueTooLarge)
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace
test chainstate::stacks::boot::contract_tests::pox_4_instantiates ... FAILED"

But if I change the second list value to a much smaller number, such as a max of 10 shares per signer, the test passes. Are we running into a cost-run limit here with that nested list structure? If so does this mean we need to cut back on total signers or total shares per signer? @jcnelson @jferrant

[jcnelson]

But if I change the second list value to a much smaller number, such as a max of 10 shares per signer, the test passes. Are we running into a cost-run limit here with that nested list structure? If so does this mean we need to cut back on total signers or total shares per signer?

It means you probably need to use one or more data maps and divide up that list into individual records per signer.

[setzeus]

While there still a few in-flight PRs for PoX-4, both #4209 & #4239 closed out this story.