This questions has been asked a couple times and so I wanted to collect my thoughts on what Clovers as a state channel might look like, why it might not be ideal, and how ideas related to state channels might be useful.
From my understanding, and please correct me if i’m wrong, a state channel is series of trustless interactions between individuals (and under certain situations multi-party) that have a recourse for on-chain resolution when disputes over the interactions occur. Participants sign messages that signify intention for an action without having to submit that action to a chain. So long as they’re in agreement about each other’s actions and have proof of those actions via signed messages, there is no reason for either of them to go to a chain to be recorded (or until the interactions come to an end). However if there is a discrepancy that’s when the signed messages would be used as proof of an actual state and used to force that state on chain.
With Clovers that would mean someone (probably me) would be in charge of keeping track of some global state of Clovers, all probably recorded in some off chain database, each one with some signed messages from the person who found it and some mediator. So with the most simple version of Clovers (no rewards, no clover coin) a user story might look like: I’m a user who just found a clover and I want to keep it. I establish a connection to the state channel by making a transaction on the state channel’s contract root of trust (or something the details here i’m a little hazy on). Then I send my clover solution to someone else in the state channel and wait until they acknowledge that I have signed a message that includes my clover moves. Alternatively I would sent the commit hash of my moves and wait until someone has acknowledged that i made that message, by also signing my message. Then I could make my reveal message that would also need to get acknowledged by another party. This other party could be anyone if this was a multi-party state channel or it would be the official Clover account if it was only 2-party state channels (again this is where the technical possibilities are still vague to me but as i understand it multi party state channels are much more difficult). Once it has been established that I found this Clover and that there is proof from one or more parties that acknowledge that I found this Clover then the off-chain database would update with my new Clover and me as the owner of it.
In the multi-party scenario there could be a problem where two people both try to register the same Clover. Party 1 gets proof from Party 2 that they found it, but Party 3 gets proof from Party 4 that they found it. With state channels you include a nonce which tells the order of your signed messages, but there’s no way to prove what time those messages were signed. So if Party 3 tries to get another piece of proof from Party 2, you could prove that Party 2 signed Party 1s Clover solution before signing Party 3s Clover solution. However you could not prove whether Party 4 signed the proof before Party 2. This creates a race condition that isn’t easily resolved (or not possible as all).
Another problem occurs when you have assets like Clovers as NFTs that will want to exist on-chain at some point. Maybe they don’t need to be on-chain if they are just being owned by the owner, but say they want to transfer them to another owner who only uses Open Sea and doens’t have an established root of trust on the state channel. They need to transfer the NFT to the blockchain to do so. This would be an action that is possible on the state channel but one that would requirea weird mix of some Clovers existing on-chain and in the state channel, and some only existing in the state channel. The NFT contract would need to take the State Channel contract as the authority over minting and burning NFTs (which is no different if there were a side chain doing this work). But the event of the race condition becomes a problem when one party wants to move off an NFT that another party claims to own and claims to have proof to own. How do you resolve the real owner when you can’t determine the proper order of events?
Now this problem could be mitigated by the two-party state channel situation. In that scenario all connections would be established between a user and an official Clovers point of contact (me). Then that point of contact would sign the messages proving ownership, and make sure not to sign the same clover to different people. When they want to move it on chain they would also be able to, if for some reason I am unwilling to acknowledge that you own a Clover, you should have proof that I already said it was OK. This is the scenario that might necessitate a state channel, as it is really a system of recourse over disputed state. However I think it is a bit of an edge case, and the fact that all of the Clovers only exist off-chain might also be a drawback for users who are used to their NFTs showing up automatically in their wallets and on opensea.
Something useful from this configuration that is in the works at the moment is the idea that there could be a trusted authority that verified Clovers. This is similar to the current oracle method, except the current oracle method puts everything into the contract. An alternative configuration would be that users send their clover moves to this authority to sign the clover if it is in fact valid. Then this signature can be used on chain as the key to redeem the actual Clover. There is no race condition because the important part of ordering the transacitons takes place on the blockchain itself instead of off chain where timestamps can’t be verified. I would happily verify the same Clover for two different people if they both independently found it. It would be up to them as to who submitted it to the contract first to determine who actually gets to keep it.
Another similar situation with even less centralization would be using a third party blockchain as the authorized entity. Say we used the xDai chain from POA network or the POA chain itself as the verification process. The verification could be run on-chain in these cheap locations and then the result could be relayed back to the original chain as proof. Of course a contract can’t sign a transaction, but if that chain had a bridge the results could be easily relayed back to Ethereum. If the third party transactions were cheap enough it could also be paid for potentially by Clovers itself (maybe refunded when the user collects the Clover). This is another option I’d like to consider to help minimize the cost of minting new Clovers.