Hey @middlemarch I love the “bring your own auth” style auth registry you have here. Proving times for client-side normal/recursive ZKPs have gotten fast enough to make this a viable and better approach than keystore implementations in shielded pools I’ve attempted in the past in solo projects.
That said, I have some feedback on this proposal for possible improvement:
- Add a
dataparam innoteBodyCommitmenthash.datacan be either a hash of arbitrary data or default0value. Combined with custom auth circuits, you can enable some levels of private DeFi entirely within the shielded pool by having programmable spending rules in the notes. It would be limited compared to Aztec and others, but still enables more than just simple private transfers. I built a private escrow proof-of-concept experimenting with this that you can check out for reference. - Add a
tokenIdparam innoteBodyCommitmentto also accept other token standards. I don’t believe a canonical privacy layer should be restricted to only ETH and ERC20 tokens. It would be a minimal change to support other common token standards ERC721, ERC1155, and ERC6909. For ERC20 and ETH,tokenIdwould be0. This opens up more use-cases like opening a borrow position in Liquity (mints a trove NFT and BOLD tokens) and hold that position privately in the shielded pool.
Lastly, and hopefully this does not come off as a shill, I recently drafted ERC-8290 which may also solve the anonymity set chicken-and-egg problem but quite complementary with this proposal. As rollups and other chains are building their own privacy solutions (or adopt EIP-8182 themselves), this might be a solution to interoperate with them and combine anonymity sets in the future. At the very least, this could resolve the concerns of EIP-8182 monopolizing privacy on L1. Just putting it in your radar for future consideration to include in EIP-8182 (may or may not be a fit) or other privacy protocols to inherit EIP-8182’s privacy depending on how the space develops.