Publicly owned mutable state using anyonecanspend UTXO

[adambor]

To my knowledge (I might well be wrong) currently there is no way in RGB to define an unowned mutable state that is public, this might be a hurdle when implementing AMM swap pools (like Uniswap), lending pools (like Aave), DAO treasuries and possibly other things.

I am drawing inspiration from Prime "merge mining", where there is a defined anyonecanspend seal that is then spent to commit to new block and create the next anyonecanspend output. I believe similar approach could be used to allow for unowned publicly mutable state in RGB - an anyonecanspend single use seal is created at the contract genesis, that can be spent by anyone to advance the state of the contract (make a trade with AMM, borrow from lending pool, deposit/withdraw from DAO treasury) and create a new anyonecanspend single use seal to be used by the next user of the contract. In case the anyonecanspend output is griefed (spent without committing to a valid state transition) the protocol reset happens with OP_RETURN (same as described in prime paper), and the state should be re-allocated to this newly created anyonecanspend single use seal.

The problem I see with such a solution is mainly data availability, in case you spend the single use seal, and commit to the state transition that you then don't make publicly available others cannot continue advancing the state and a protocol reset needs to happen. A different problem is how can you prove that you really published the state transition and it is publicly available - because otherwise anyone can trigger a protocol reset at any time and this essentially invalidates your latest state transition.

The reason I am starting this discussion is to see if building something like this would be possible with current RGB capabilities, or if there are other known ways to have unowned public mutable state in RGB, lastly I am interested to see your views on the proposal and problems mentioned.

[cryptoquick]

Global mutable state via an anyonecanspend output is a very clever idea worth exploring. It might be useful in things like RGB24 decentralized DNS.

[dr-orlovsky]

How could you forget about the global state in RGB?

And no, RGB24 doesn't need anyonecanspend to work at all.

[cryptoquick]

Haha, don't break my heart, Maxim. I'm not denying global mutable state is impossible, I'm saying it'd be neat to do it via anyonecanspend.

From my understanding, global state is defined upon contract creation, and can only be modified if in the schema there is support for owned state modifiers. If these seals are anchored to anyonecanspend, then it's essentially permissionless global mutable state, which is perhaps how I should have phrased it.

However, you are correct in that there's no guarantee a valid state transition is made. Prime handles this scenario with the capability to announce a protocol reset. I'm not sure how well this will work with an RGB contract, but I'm also not sure how well it would work with Prime, either. Maybe if protocol reset txs can be made to work with Prime, perhaps they can also be made to work with RGB contracts.

[dr-orlovsky]

From my understanding, global state is defined upon contract creation, and can only be modified if in the schema there is support for owned state modifiers.

This is not correct. Global state can be modified by any party of the contract - or even by external parties if it is allowed by state extensions.

Anyonecanspend will not work for RGB and the whole work on v10 with global state and consensus ordering had happened because of that. Unlike with Prime, where "protocol reset" can be defined at the consensus level, in RGB it is on the client-side, and thus can't be used. But even if it can, there is no point, since it requires much more complex logic + price of an onchain tx for things which can be done without that using existing global state mechanics.

[dr-orlovsky]

To my knowledge (I might well be wrong) currently there is no way in RGB to define an unowned mutable state that is public,

That is incorrect. There is a global state which is "unowned" (i.e. is not backed by UTXO).

where there is a defined anyonecanspend seal that is then spent to commit to new block and create the next anyonecanspend output

and what if someone spends it without creating a proper commitment?

Anyway, this is a non-issue since the existing RGB global state was specifically designed to allow AMM-like functionality

[adambor]

Alright, cool that global state is something already included in RGB. Are there any resources describing how it works?

[dr-orlovsky]

1. https://github.com/orgs/RGB-WG/discussions/219, check "Global state" part
2. https://github.com/orgs/RGB-WG/discussions/218

[LeroiHEtevis]

I am watching how this whole structure is developing and I am very surprised how quickly it is happening.

[CodeDiva23]

Honestly speaking, this is the first time I’ve encountered this! I wish you could solve the problem