Brainstorm features and decide on priorities

[hackaugusto]

Here is an incomplete and unordered list of features to discuss and set priorities. It would be good to collect some other use cases that can affect design

• Front running protection
• Miner Extracted Value protection
• Censorship resistance
• Flash loans
• Private transfers to offline users
  • onboarding
• Fees payments with any asset

[Dominik1999]

I want to add the following:

• composability within Miden (a smart contract on Miden can call another smart contract in Miden) - how does this work with which level of privacy
• composability cross-l2s (a smart contract on Miden can call another smart contract on another Rollup) - how does this work with which level of privacy
• data availability and backups (should we have a service for users to store state?)
• outsourcing the local proof generation - do we want to have a standard/service for that?
• general fee mechanism (do we need a buffer for ETH fluctuations)
• desired finality (L1 and L2 finality)

[hackaugusto]

Targets / environments:

• mobile phones
  • what are the minimum specs?
  • what are the features we want to support?
    • proof generation? proof verification?
    • light clients?
• web browsers
  • in-browser transaction signing with WASM?
  • light client?
• external wallets?

[bobbinth]

I think this is more of a question of what is practical to support now. From UX perspective, the biggest issue would be the time it takes to generate a proof - I think anything more than 3 - 5 seconds would probably be unacceptable.

Given the above constraint, I think proof generation on mobile phones or even in browsers will probably not be practical in the near future (i.e., 1 year) - though, it really depends on how much effort we want to put into trying to make it work.

This does not exclude the ability of mobile phones and browsers to execute a transaction and then send it to the network to be proven (or even delegate to some 3rd party to generate a proof). So, my thinking is that initially, local proof generation would require something like a mid-range or high-end laptop (like a MacBook Air), and devices which are not as powerful would execute transactions locally but would delegate proof generation to the network (or some other 3rd party).

[Dominik1999]

I think those discussions are super helpful. For the PoC I think we can stick to a high-end consumer laptop. And then, I would go with the early user feedback. It highly depends on the use cases I would think about which targets we might have.

[hackaugusto]

notes of our meeting on 17/Feb/23:

• onboarding users
  • account creation requires a transaction, a transaction will have to pay gas, this means that onboarding users on the testnet will require a token faucet
    • is there an easier solution?
      • having a permissionless approach to block sealing and paying people in tokens to mine for the testnet would be an approach, at the cost of complexity (the PoC will have a single sequencer)
    • if we do end up with the faucet solution, what is the approach we will take to prevent hoarding?
      • cool off by ip address? email/phone verification? mining on the account address?
  • how will the flow look for onboarding without a faucet/airdrop?
    • a solution for this is to use a pay-to-hash, the user would acquire tokens on some exchange and the exchange would create a note with a pay-to-hash to a hash provided by the user
      • this means that a sequencer has to look at both the input's note vault and the target account's vault as an heuristic to decide if there is enough gas to pay for a transaction
        • can this be simplified?
• note consumption ordering
  • the ordering transactions are added into a block is a form of miner extracted value, can we prevent it?
  • can we impose an order? perhaps based on the note creation order?
• opportunity cost for dex
  • the note's script defines which accounts can consume the note
  • a trade will require a minimum of two notes, notes that are deeper in a order book will take longer to be consumed meaning a larger opportunity cost, can we decrease that?
    • an idea is to allow a single note to target multiple dex, there will still be a cost, but at least the market maker is not tied up to a single exchange
    • @bobbinth also suggest a multi-account transaction kernel which would allow for atomic exchange, without a note creation, so there won't be a need to allocate the funds on a note
    • another idea is that a note could have multiple execution paths. for a selling order a note would each path would corresponding to a different price, the user would start revealing the code path that corresponds to the higest price, and would keep the other branches hidden, gradually the user can reveal the MAST of the different branches, each new branch with a lower selling price. This way a single note can be used to represent multiple orders, and the user doesn't have to consume/create a new note every time they want to change the order price