You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Ferveo's paper and implementation use what they call a "fast" approach for Threshold Decryption, as opposed to the "Simple" method ("Fast" and "Simple" being the terms used in their docs). The reality is a bit more nuanced and it has implications for us.
The "Fast" method is actually a trade-off where they optimize the threshold decryption step over the combine step. That makes sense for their use case, where Ferveo is used during a block production stage to decrypt encrypted TXs; since in that stage the validator set that decrypts is fixed and reused for many TXs, it makes sense to reduce the individual decryption time, while reusing intermediate computations in the combine step that are depended on the validator set (i.e., Lagrange coefficients). The way to do this is to kick the can down the road at decryption time, so validators don't actually create decryption shares (which would require computing a pairing) but some blinded values (which only require an EC multiplication) that can be later combined with known information from the DKG ritual at the combine step. In short, the implications of the "fast" method are:
Optimizing decryption over combination
Combination is now heavier (as the pairings you're not doing at decryption time need to be done anyway at combine time) and requires knowledge of some DKG ritual information
The "simple" method is a more balanced approach, where pairings are done at each individual decryption request, and the combination is "merely" a bunch of EC multiplications (although in the much harder group $\mathbb G_T$). For our use case, it makes sense to try to reduce the combine step as much as possible as it will be done by Bob in the browser (potentially by a Porter instance if it's trusted enough).
To me this points towards changing Ferveo to implement the "simple" version, which is also...simpler, as you don't need to introduce this intermediate blinding step. Since they prepare these blinding values at the DKG stage, this also has implications on the DKG implementation.
The text was updated successfully, but these errors were encountered:
Looking at how validator's shares and their verification are defined for the "fast" method:
A blinded public key, $$Pi=[b]H$$
A validator's share, $$Di=[b−1]U$$
Verification, $$e(Di,Pi)=e(U,H)$$
Whereas the key share for the "simple" method is defined as: $$Ci=e(U,Zi)$$
Is this property interesting to us? Should we reconsider using the "fast" method?
Ferveo's paper and implementation use what they call a "fast" approach for Threshold Decryption, as opposed to the "Simple" method ("Fast" and "Simple" being the terms used in their docs). The reality is a bit more nuanced and it has implications for us.
The "Fast" method is actually a trade-off where they optimize the threshold decryption step over the combine step. That makes sense for their use case, where Ferveo is used during a block production stage to decrypt encrypted TXs; since in that stage the validator set that decrypts is fixed and reused for many TXs, it makes sense to reduce the individual decryption time, while reusing intermediate computations in the combine step that are depended on the validator set (i.e., Lagrange coefficients). The way to do this is to kick the can down the road at decryption time, so validators don't actually create decryption shares (which would require computing a pairing) but some blinded values (which only require an EC multiplication) that can be later combined with known information from the DKG ritual at the combine step. In short, the implications of the "fast" method are:
The "simple" method is a more balanced approach, where pairings are done at each individual decryption request, and the combination is "merely" a bunch of EC multiplications (although in the much harder group$\mathbb G_T$ ). For our use case, it makes sense to try to reduce the combine step as much as possible as it will be done by Bob in the browser (potentially by a Porter instance if it's trusted enough).
To me this points towards changing Ferveo to implement the "simple" version, which is also...simpler, as you don't need to introduce this intermediate blinding step. Since they prepare these blinding values at the DKG stage, this also has implications on the DKG implementation.
The text was updated successfully, but these errors were encountered: