[Sprint 1] Goal proposals: Vertical state channels

[sadiqevani]

Goal proposals: Vertical state channels

Proposed goals (Sprint 1 - end 5th of February)

• Michal: Not important in the long term but as a short term solution it would be nice to display epoch node logs. That's because state channels api don't return messages for all errors and are logged instead (I believe there's a roadmap ticket to improve this).

• Philipp: I agree with Ulf, I find this a pretty good view of the state channel, in addition to visualize even more in which "generation" one state channel is currently and what the current state looks like.

  Focus should be on smart contracts in the state channel, integration with forgae would be important to me if I consider using the tool seriously, integration with the contracts editor just to play around.

  I think it is very important for the project to find a very minimal mvp that can be used independently and would de already helpful. That should also be feasible in a sprint, the big idea I've seen so far is a project that takes forever to implement and where during the development also much unpredictable changes. So in this case small iterations would work the best, where every part has got an own value for the end user.

• Sadi: For me a lot of features that I had in mind are already writen, currently I don't have any specific feature that I would like to implement, except for a multi-identity system, where we can gain signing or pub/priv keys from a trusted source, or work in a way that is safe for everyone.

  I would say that for the initial Alpha version what is achievable is:

    - Build the UI of the app
    - Build a hardcoded demo of the channels interacting
    - Having one (or more) node locally
    - Figuring out a way for logging transactions and events.
    - Learning more about the SDK and the Node API (what is possible for now and what is not)
  

• Dimitar: I am not sure what the scope of the MVP would be, but what I got is the aim is to provide an infrastructure to run channel's apps. Since a channel can have multiple contracts running simultaneously, it would be great if at the end the infrastructure provides:

  1. Having a couple of different contracts/apps running in a channel
     • create new app inside a channel - that could be as simple as creating a new contract that has some preset contract-specific UI
     • execute an application functionality/a contract inside the channel - from an user's perspective that could be as simple as clicking a button
     • list all apps in the channel
     • uninstall an app/contract - for this you'd need some aeternity node support that is not there yet

  This will allow us to install for example a chess app as well as flip-a-coin app in the same channel, later on to view them and delete one of them.

  2. Keys and signatures isolation - so we don't put keys in every single app. Probably a subscription mechanism for auto-signing incoming valid updates. This could be later replaced by a proper wallet, handling the signing.

  Note: I am not sure which of those shall be included in and to what degree a MVP, probably keeping them in mind would be nice.

• Ulf: It would be nice to be able to view something along the lines of a sequence-chart-style event view (that was the one I could find quickly; it allows for clicking on each line for more detail.)

• Nikita:
  important note: Please don't use the term apps in this context, I think we are actually talking about contracts here? Because later, if we would be talking about "debugging an app" this could mean any layer of the whole architecture stack, although we actually mean the smart contract (or something totally different)

• Dario:
  all features (not only for the MVP)

State channel monitor/inspector

• list all contract in the channel
• transaction history
• events timeline
• state history (for each participants)

State channel manager

• create new contract inside a channel
• uninstall an app/contract
• alterate the state history of a participant
  eg. create a conflict in order to force a dispute on chain

Aepp Emulator

• Create channel / Deposit / Withdraw / Close channel / Channel Accept
• use the aepps
• offline emulator

Project Loader / Archive

• Create Project
• Save Project
• Open Project

Playground Templates

• 2 Emulators
• 1 Emulator + 1 Remote device (outside the playground)

Terminal/Console

• one console for each app
• general console??

Identity handling

• default/hardcoded accounts
  viable only on local network

• temporary accounts
  create accounts in setup phase

• identity provider
  wallet connection

Permissions & settings

• auto-signing
  state updates / small transfer (<limit) ...

• account access
  grant æpps access to account/s (in wallet?? standard interface for identity provider?? )

5. Setup environment (more steps will be added/ feel free to add):

1. Docker setup with Shubhendu or Andrea
2. Setup aepps/playground GitHub repo
3. Setup VueJS App
4. Warpping mock-up into Vue App

Q/A

Few Q/A related to state channels and aeternity node.

Questions

1. Do state channels need 1 node between two parties?
2. Can I generate multiple state channels on a one-to-one basis for multiple people within one node?
3. Have you done work on integrating the Identity + App itself through a framework?
4. Are there any guards when it comes to StateChannels JS API?
5. I saw that there's several guards onTx, onAccount, etc... Or they would be the same guards for off-chain transactions, etc.

Answers

1. You can connect both participants to the same node or each one to separate nodes.
2. Yes you can create multiple state channels. The only thing to bear in mind is that you need to use different port param for each state channel.
3. I was considering playing with it but at that time it wasn't ready (not sure how it is now).
4. There are no guards similar to that in Wallet but there's sign parameter which is responsible for signing incoming transaction (sign(tag, tx) { //... where first param is transaction type and second is transaction to sign or reject [by returning null]).
5. See above reply. I think that in the future we might consider creating guards similar to these in other places (onUpdate, onMutualClose etc.) to make it consistent.

MVP features

1. create new app inside a channel
2. create new contract inside a channel
3. execute an application functionality/a contract inside the channel
4. aettos for channels
5. Integration with forgAE
6. Integration with the contracts editor

Reference: https://hackmd.aepps.com/s/B1BNGaNX4