Collective curation of topics to go in resource machine report v2

Protocol Design
1

None of this is urgent, but noted for posterity.

  • Pre-ordering execution on local nodes to e.g. select resources to sum up to a particular balance. validityProofTransform operation of type Tx -> Tx to convert transparent proofs to ZK proofs etc. See notes on execution flow here. Next steps: @cwgoes to write forum post and make proposal more explicit.
  • Proposal for how to integrate forall & negative checks.
  • Balancing signature folding proofs etc. (see notes here).
  • How to combine Nockma transaction candidate code pre-ordering. @cwgoes to write a forum post about this (might be the same one as pre-ordering execution).
  • Distributed partial evaluation analogy (see here). May or may not need to go into the report itself, but worth working out and writing up.
  • Built-in / sentinel resources in order to insert oracle data (e.g. timestamp) - this will require non-linear resources, otherwise we might not need to change anything - but we should work out in detail.

cc @vveiln @degregat

1 Like
2

Another set of related topics from a discussion with @vveiln:

  • Distinction between transaction candidate and transaction types. In particular, if we conceptualize a transaction candidate as a function StateAccessors \to Transaction, where StateAccessors gives some ability to read resources, indices, etc. (as is already specced), we might be able to define most of our operations (e.g. composition, validity) over this type, with the special case of a constant function being the way we have currently defined them.
  • Figure out how proof creation should work, exactly, as operations on these data structures - do we just need creation and composition? Do we need some function to transform transparent proofs to ZK proofs? etc.
3

Another set of related topics from a discussion with @mariari:

  • We should define times of execution more clearly - for example, post-ordering (for a given transaction, when all relevant controllers have attested to the transaction’s place in their total order, possibly with a chimera chain), pre-ordering (this is actually a set of many different times).
4

Another set of related topics from a discussion with @vveiln @degregat:

  • Figure out what to do with proof conversion e.g. upgrade to ZK, downgrade from ZK, how this relates to information flow control, observer-dependent verify function (e.g. given known trust, transparent proofs can be replaced with signatures), etc.
  • This should be analyzed in tandem with information flow control for transactions.
  • Figure out information revelation (e.g. choosing to reveal resources, keys, etc. to various parties)
5

Another random topic: would designated-verifier proofs be useful?

6

Possible (additional) topics for v3:

  • “Shallow” and “deep” EVM integration
  • Generalized information revelation (proofs to third parties)
  • Further examples
    • Asynchronous co-processing (e.g. Ferveo)
    • How integration of FHE would work
    • Reference 1
7
  • Cross-proof-system interoperability
1 Like
8

For tracking purposes, a list of all topics here, marking the ones that were already covered:

General:

  • pre- and post-ordering
  • forall & negative checks
  • transaction function composition; define all operations on transaction functions instead of/in addition to transactions
  • non-linear resources
  • EVM integration
  • more examples
    • async co-processing
    • FHE integration
    • this

Information flow control:

  • cross-proof-system interoperability
  • generalized information revelation
  • would designated-verifier proofs be useful?
  • information revelation to different parties: explicitly define what and to whom
    • this also relates to the balancing signature topic
  • transitions between transparent and zk proofs
  • IFC for transactions

Out of the report scope:

  • distributed partial evaluation
    • should be written down somewhere
  • balancing signature business
    • worked on; taiga-specific
2 Likes