Identity-based policy signatures #33
Description
This is an extension of #31. As currently implemented at the time of writing, policies only allow one type of signature: admin key signatures. This means that a policy needs to have a specific set of admin keys in order to be valid. This works, but is somewhat brittle. The idea behind Stamp's key system is that policies and admin keys can shift and change over time as needed. Requiring outside policies to update every time this happens creates friction.
While it makes sense to retain the ability to require signatures from a specific admin key, we should also allow signatures from the TransactionBody::SignV1 transaction. However, this alone would require a shitty lookup (or even multiple) with every signature. Instead shipping the signature transaction and proof that it is valid is ideal.
As it stands, it seems the only way to do this is to pass a chain of transactions (ie, the identity itself). However, this could get bloated really fast. It makes sense to only ship transactions that update the identity's policies and admin keys. We can do this by using some kind of skip list...we track two sets of previous_transactions: the standard one which lists the transactions that came before, and policy_transactions which only links back to transactions affecting admin keys or policies (and obviously the genesis). Then we can ship valid but condensed identity objects with our signature transaction that can be verified on the spot. This means that any valid signature from the identity would satisfy the policy condition (as opposed to a specific key).
I'm curious if there's a more condensed way of doing this. ZKPs seemed initially promising, but proving a chain of transactions that require multiple signatures to be valid seems ...tricky. The entire stamp protocol would have to be encoded into some kind of ZKP solver, which would be a feat in itself. I'm wondering if the skip list is the best way of going about this.