We want to ensure that the staked funds corresponds with the committed messages (which contain all the hashes of the fragments).
There are two approaches:
Make the "propose" and "create" steps atomic. Since createMessage consumes the hash of the IPFS location, the file must have already been uploaded (complete with all the fragments encrypted with revealers' public keys.) This requires the revealers to be "pre-selected" before performing the propose-create atomic action.
Do some internal accounting to keep track of which funds have been staked for a secret revealing scheme that is actually active.
We're going with the simpler approach (1.) for now.
Ask each revealer to set total stake and stake per message.
Client pulls eligible revealers from contract and decides which to pick (given total stake, available stake, stake per message). To avoid a race condition in most cases, client can choose revealers that have a lot of available stake.
Client creates message with revealers from step (2).
We want to ensure that the staked funds corresponds with the committed messages (which contain all the hashes of the fragments).
There are two approaches:
Make the "propose" and "create" steps atomic. Since createMessage consumes the hash of the IPFS location, the file must have already been uploaded (complete with all the fragments encrypted with revealers' public keys.) This requires the revealers to be "pre-selected" before performing the propose-create atomic action.
Do some internal accounting to keep track of which funds have been staked for a secret revealing scheme that is actually active.
We're going with the simpler approach (1.) for now.