I took a look at your proposal. My immediate reaction to the idea of a smart contracts working group is that it is a good idea. Smart contracts are the thing that attracted me to blockchain personally, but there remains a level of equivocation about what they are. The pragmatic model more favoured in Hyperledger seems to be 'they are just code that runs on a blockchain', the straw man model (since I think few people think this way post-DAO) is 'code is law', in fact probably the concept could be usefully unbundled, so I like the suggestion of a taxonomy as a primary output of a Smart Contract WG.
Some research topics and separation I would be interested in are:
- Models of and mechanism for computation, such as:
- Stack machines vs automata vs manipulating algebraic types embedded in a another language
- Scope for less expressive languages (that may have more tractability for formal methods)
- Execution determinism, and sources of non-determinism in existing languages
- Cost models for metering computation (e.g. gas)
- Paradigms for smart contracts - e.g. 'identity-oriented', functional, process-oriented - extent to which smart contracts benefit from special purpose languages
- Parallelism of execution, state independence (i.e. parallel processing in a single block)
- Formal guarantees on outputs of smart contracts
- Smart contract packaging, code reuse, and dependency auditing
- Smart contracts as representatives of obligations and fulfilment (i.e. 'law')
- What properties should smart contracts with 'legal charge' have?
- What relations can smart contracts have with actual contracts and agreements?
- At what scale to smart contracts best contribute to certainty and execution of agreement?
- What relationship do legal smart contracts have to models of computation?
- Generation of smart contracts from existing artefacts (natural language, business process, state machines, non smart-contract code)
- Data structures and state
- Verifiable and authenticated data structures - e.g. merkle dags, log-backed maps,
- How best to expose through smart contract languages/libraries
- Sharing state backends across execution engines
- Conflict-free and additive data structures
- Multi-party secure computation
- Differential privacy
- Zero knowledge and practical building blocks - types of commitments and witnesses
- Tooling and compilers for existing virtual machines
I think for a Hyperledger working group a good output would be to find practical ways to connect stuff 'out there' with things we could use within our implementations. I'd like to see a group that could survey the state of the art and academic content and produce 'Requests To Build' that could feed into feature planning on the frameworks.