SpankChain/general-state-channels

Potential typo in deployCTF?

Opened this issue · 3 comments

https://github.com/SpankChain/general-state-channels/blob/master/contracts/ChannelRegistry.sol#L30

In the part of the code that should check the signatures of the bytecode to be deployed, the for loop is initialized at 2 and check if it's less than 2, so the for loop never enters.

Yes good catch. And thanks for the eyes on the repo! Please feel free to fork and put in a small pull request to fix this if you would like a contribution on the project.

I plan to do some big overhauls to this in the coming days including...

  • Building a roadmap and contributions guidelines.
  • Start weekly updates that I will be putting out in the form of a captains log git issue. (daviddias ipfs inspired)
  • Refactor Bond Manager (moving towards Stefan's Gnosis Safe)
  • Refactoring state representation (Optimize for efficiency)
  • "Merkelize" state, sign and store root hashes, and add inclusion proofs. (this will allow state to be modular and for interpreters to only need to care about the subset of state they are responsible for decoding. This should increase the theoretical limit of open channels to the complexity of proving inclusion of correct subset state (O(log N)) and the reconstruction of that specific state (O(c)).
  • Add real tests for the current support channels
    • Single Direction Payment
    • Bidrectional Payment
    • Crypto Kitties Battle Game
    • Any other module that others would like as a sub-channel
  • Work on a hub that can handle connections to many users and all sub-channel systems.
  • Discuss representing state as a pool of transactions that could be executed on chain. Form a merkle root of all transactions that lead to an agreed upon current state. In the event of a final state challenge, highest nonce merkle roots may be stored in the channel manager that define a set of transactions that will lead to a final balance for the multisig. A proof of inclusion will be ran against the current highest nonce root when transactions are ran against now deployed state channels.

OK cool, I'm glad this will be moving forward, I'm working currently at my company on utilizing state channels for games and developing and library around it and your research is very helpful.

The Merkalized state is a very interesting approach as logic for some games (other stuff as well) can get quite heavy and onchain resolution may be too costly. We've been thinking of some ways to split the logic up so you only need to handle a subset of computation.

"Discuss representing state as a pool of transactions that could be executed on chain. Form a merkle root of all transactions that lead to an agreed upon current state." - So basically a block of transactions? :D
Not sure if I quite understood the last part but sounds interesting.

@yippee-ki-yay essentially that's what he's describing is a block of transactions. The main takeaway is that they are externalized and the proof exists, and how you assemble to that proof is the key consideration.