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
policy: reduce error paths in Concrete::extract_key to one
The Taproot compiler has a couple algorithms used to find an optimal
internal key to extract from a policy. One is `to_tapleaf_prob_vec`
which is a fundamental part of the compiler, which iterates over the
disjunction-only root of the tree and returns every branch along with
its probabilities.
This is currently implemented using both allocations and recursion. By
pulling the logic out into an iterator we can get a clearer, faster
algorithm that cannot stack-overflow.
This algorithm is then fed into Concrete::extract_key. The goal of this
algorithm is to find the highest-probability tapbranch consisting of
just a single key. This algorithm inexplicably works by:
* Lifting the policy to a semantic policy, maybe returning an error
* Iterating over the entire policy, extracting a list of every key.
* Calling to_tapleaf_prob_vec to get a vector of tapleaves, which it
then iterates over to find the key-only branches, which it collects
into a BTreeMap mapping the key to probabilities.
* Iterating over the extracted lists of keys, and for each key, reducing
the semantic policy by that key and comparing to Trivial (logically,
this is asking "is this key in a tree of disjunctions from the root").
* For each such key that it finds, looking it up in the map, potentially
returning an error (actually this error path is impossible to hit).
* and manually minimizing the looked up probability.
With to_tapleaf_prob_vec replaced by an iterator there is a simpler and
more direct algorithm:
* Iterate through all the tapbranches/probability pairs, filtering for
key-only branches, and maximizing by probability.
This can only fail if there are no key-only branches, and this is
reflected by only having one error branch.
0 commit comments