stacks-network
[Nakamoto] Usefulness of StackerDB trait in smart contracts
The StackerDB contract trait is currently made to be consumed by an off-chain process (signer binary). Thus, the trait returns the signers as a max length 4000 list of tuples. It allows the off-chain process to fetch the signer set in one call but it makes using the information on-chain very cumbersome and expensive. Lists, especially long ones, are not particularly efficient to use in Clarity.
I'm opening this issue to discuss the current design of the trait. Once #4263 is merged perhaps we can examine it more closely. I think the design of the contract hinges on this question:
Is the information in the StackerDB contract useful for other smart contracts?
If yes, then I suggest we need to change the design to make querying the signer set easier.
The voting contract is an apparent use case. @friedger wants to be able to pull the number of slots of a particular signer key to be able to validate the vote and assign weight when an aggregate key vote comes in. At the moment, the options are to pull the list via stackerdb-get-signer-slots and iterate over the entire list or to pull data from PoX4 using get-reward-set-pox-address.
It would be much better if the StackerDB contract trait admitted a function as follows:
(define-read-only (stackerdb-get-signer-slots (signer principal)))
However, it means that the node has to write the signer set to the contract twice, once as a list and once as a map.
Removing Argon tag since this a conversation worth having but doesn't block Argon release, StackerDB trait not useful for anything off-chain stuff, do we want to expose this? Such as a DAO of signers?
If we don't have a clear example let's leave it towards past Argon.
Considering moving to discussion.
