The short answer is that although there is an audit trail on the backend it wouldn’t help at all with the type of review being discussed. While Submittable has met many of our needs over the past years it’s far from perfect, especially when it comes to this type of grant comparison. I wish I could provide a more helpful response!
We timed the Submittable contract renewal so that ZCG could decide what direction to take in November. FWIW, I personally 100% support a move to GitHub (or another solution if one is found). It’s time to try something new and the timing is perfect with the upcoming ZCG move to FPF.
For completeness, here’s the Asset Swap milestones from the original proposal:
From this original grant, we’ve done part 1 (ZIPs), we’re now proposing part 2 (implementation)
As noted above, part 2 was replaced with Development in Support of Zebra, specifically Deliverables 7.1, 8.1, 11.1. You can see the replaced milestones here.
We will apply for a separate grant for part 3 when it’s ready. Part 3 depends on progress from ECC/ZF (integration of asset swap), it’s not included in this new grant, because it’s in the future and requires more effort and funding than what ZCG wished to allocate for the current grant, already including the Transaction Acceptance work.
Hope that clarifies the grant, thanks for helping us put this on the record.
Btw a move to Github would make our lives easier, Submittable is cool but we do prefer our local editors and history + state management for exactly the current usage.
@vivek at the most recent meeting, the @ZcashGrants Committee voted to approve this proposal and has requested that you provide monthly updates via the forum in this thread.
We have begun updating the orchard crate to add support for Action Groups as proposed in ZIP 228.
We are currently working through what changes to the OrchardZSA circuit (if any) would be required in order to securely allow for Swaps.
We are also in the midst of creating new data structures / updating existing ones for the Orchard Bundle, the Orchard Action, and the Orchard Action Group.
While the protocol itself will require development and tests in the repositories listed in the previous section, actual use by the community would require the ability to create Swap Orders, and also to match these Swap Orders, create a Swap Bundle, and submit that on chain.
The Matcher is designed to collect Swap Orders, match them efficiently, combine them, and submit the complete Swap Bundles to the blockchain.
The architectural design for the Matcher is currently underway.
We will also be updating our zcash_tx_tool, which we have been using to generate transactions for Zebra nodes, to also be able to generate Swap Orders on the client side.
Transaction Acceptance (User Control) Design
We have begun research into possible designs to add the proposed ability to accept / reject incoming transactions.
Here’s a list of some of the questions we are thinking about in this regard. Please feel free to raise more!
One core design consideration is regarding the default behavior: i.e. requiring explicit approval vs explicit rejection from the recipient. The use-cases are one way of assessing this.
What is the threat model? We have to consider in the threat model both malicious senders (who want to expose other users to Assets they do not consent to, for example), and malicious recipients (who could try to hold up funds by not providing explicit approval, or fall back on deniability if they didn’t provide explicit rejection).
Should the approval/rejection of a transaction be stored on chain, or can it just happen off-chain between the sender and receiver?
Who should pay the fees, and should there be extra fees for acceptance/rejection? This is more relevant if an on-chain record is to be maintained. But the responsibility of submitting to the chain moves from the sender to the recipient (post-approval), which needs to be considered as well.
Extent: Should this user control extend to every transaction, or only transactions of larger than a certain threshold, or only ZSAs, and so on? While answering this question we have to be mindful about indistinguishability. If we allow the choice per transaction, the choice should be the recipient’s.