The main tradeoff the approach makes (fundamental to client side validation) is that proofs increase with the number of transfers. Achieving better scaling here is desirable.
Skip Lists
One sketch of a way we can do this, is to implement a sort of skip list structure in the proof file formats. Rather than a new state transition committing to only its predecessor, what if there was a way for it to also commit to further links back into the chain? Assuming we had a sound scheme here, then we'd be able to reduce the proof size to a logarithmic length, possibly giving up a bit of soundness (probability that the asset is invalid) along the way.
Projects like fly client use a similar structure, as to other NiPoPoW schemes. However in this case they're reliant on the Pow structure to create the back links. Is there something else we can use here, or does it not matter at all?
Tombstoning
Another way to reduce proof sizes would be via the aide of the Cannonical Universe. Periodically we can essentially burn and then re-create the assets a new. The burnt assets would be probably burn on chain, with another transaction then creating the assets a new. This seems immediately practical, and mainly relies on the incentive of the asset issuer to want to be able to allow proofs sizes to remain as small as possible. A new sub-commitment would then track the set of burnt assets, and some interaction with the Universe operator would be required to re-create the assets.
This seems the most immediately practical, and rests on an assumption that the Cannonical Universe creator has some sort of influence over the assets at the end of the day (holds reserves).
NIZKP
Another way we can reduce the proof size, but increase the cost of transfers (as a tradeoff). Would be to seek out snark/stark friendly hash functions, like MiMC and use that in a new version instead of sha2 everywhere. We'd likely want to go a step further and implement certain invariants natively in the circom circuit format.
Using MiMC in the asset tree itself helps with proof complexity, but then we still need to factor in the Bitcoin side of things: sha2 hash links, the header format, the merkle tree structure, and also PoW. We may be able to solicit the recent grantee from the HRF to look into the feasibility of zk rollups on Bitcoin.
The main tradeoff the approach makes (fundamental to client side validation) is that proofs increase with the number of transfers. Achieving better scaling here is desirable.
Skip Lists
One sketch of a way we can do this, is to implement a sort of skip list structure in the proof file formats. Rather than a new state transition committing to only its predecessor, what if there was a way for it to also commit to further links back into the chain? Assuming we had a sound scheme here, then we'd be able to reduce the proof size to a logarithmic length, possibly giving up a bit of soundness (probability that the asset is invalid) along the way.
Projects like fly client use a similar structure, as to other NiPoPoW schemes. However in this case they're reliant on the Pow structure to create the back links. Is there something else we can use here, or does it not matter at all?
Tombstoning
Another way to reduce proof sizes would be via the aide of the Cannonical Universe. Periodically we can essentially burn and then re-create the assets a new. The burnt assets would be probably burn on chain, with another transaction then creating the assets a new. This seems immediately practical, and mainly relies on the incentive of the asset issuer to want to be able to allow proofs sizes to remain as small as possible. A new sub-commitment would then track the set of burnt assets, and some interaction with the Universe operator would be required to re-create the assets.
This seems the most immediately practical, and rests on an assumption that the Cannonical Universe creator has some sort of influence over the assets at the end of the day (holds reserves).
NIZKP
Another way we can reduce the proof size, but increase the cost of transfers (as a tradeoff). Would be to seek out snark/stark friendly hash functions, like MiMC and use that in a new version instead of sha2 everywhere. We'd likely want to go a step further and implement certain invariants natively in the circom circuit format.
Using MiMC in the asset tree itself helps with proof complexity, but then we still need to factor in the Bitcoin side of things: sha2 hash links, the header format, the merkle tree structure, and also PoW. We may be able to solicit the recent grantee from the HRF to look into the feasibility of zk rollups on Bitcoin.