AllWalletDevs #038
Transcript
Ask about this call
Answered from this call's summary and transcript only.
AI-generated - verify against the recording.
- patrick
Gm gm
- Sam
- lcastillo
https://github.com/ethereum/ERCs/blob/master/assets/erc-7730/example-main.json
- Sam
How are params names assigned? Would something like "erc7730:tokenPath" be a valid name? How about format? Would an ordered array be better than a single string, where the wallet picks the first format it recognizes?
- patrick
A question of mine for later… feel free to ignore for now. So ABIs aren’t enough because why? I don’t fully understand the logic there. Is it because we have to be sure the ABI is correct? Using your proposed solution is mainly just saying “this is the correct ABI for X contract, and here is how you read the parameters”… yes? Like if a malicious token had a “transfer(address to, uint256 amount)”, but it actually removed tokens from the address to , your solution would have those developers would just update the intent field of the json. Do I have that right? I think I talked myself into remembering why this proposal is good. But the “ABIs can’t be trusted” feels a little weak, just more like “ABIs are hard to read” feels more correct no?
- Hester Bruikman
Thanks for presenting this work Laurent!
- Mercy Boma Naps-Nkari
- lcastillo
@Sam params are assigned in the function name itself, which is in the form of a human readable ABI, which makes parameters names unambiguous. A parameter path like "#.tokenPath" would be valid if tokanPath appears as a parameter name in the human readbale ABI
- Humarkx
Reacted to "@Sam params are a..." with 👍
- lcastillo
For formats we never really found a use case in which multiple formats would make sense for a single parameter, but if we ever see this case it would be a possible addition
- Sam
Replying to "@Sam params are a..." I'll continue on the discussion thread
- lcastillo
@patrick indeed the issue to solve is more ABI is insufficient to represent the data to the user, more than untrusted. In fact 7730 itself doesn't solve the trust issue, a rogue contract could easily misrepresent its parameters. Which is why the governance topic with a way to audit 7730 files vs contract implementation is super important for us
- patrick
Reacted to "@patrick indeed the ..." with 👍
- Nicolas Consigny
Is there a link for both the proposal and for the hardware device presented ? This is https://gist.github.com/nailkhaf/d81c73327fefdb76fdad847035ddbc82#file-architecture-overview-md right ?
- Kirill Pimenov
We've just made the whole repo public: https://github.com/Kalapaja/clear-signing
- Kirill Pimenov
Gist above is correct, but is more of a "one-pager"
- Michael Curry
Reacted to "We've just made the ..." with 👍
- Nicolas Consigny
Nice demo, congrats !
- Michael Curry
Reacted to "Nice demo, congrats ..." with 👏
- Sam
Reacted to "Nice demo, congrat..." with 👏
- Hester Bruikman
Impressive live demo
- Hester Bruikman
Reacted to "Nice demo, congrats ..." with 👏
- Sam
+1
- patrick
Reacted to "Nice demo, congrats ..." with 👏
- Loring
Reacted to "Nice demo, congrats ..." with 👏
- Loring
EIP-8105 (Universal Enshrined Encrypted Mempool) https://eips.ethereum.org/EIPS/eip-8105
- Mercy Boma Naps-Nkari
👋 We've opened an EthMagicians thread on repo & endpoint-level versioning for the JSON-RPC API. If you build on or interact with the API, we'd love your input before we finalize v1 check it out and share your thoughts! https://ethereum-magicians.org/t/repo-endpoint-level-versioning-for-the-json-rpc-api-seeking-community/27765?u=bomanaps thank you
- Michael Curry
Reacted to "👋 We've opened an E..." with 👍
- Loring
I’m at @LoringHarkness on Telegram
- lcastillo
Thanks everyone!
- Hester Bruikman
Thanks all!
- Loring
Thank you all!
- Nail
Thanks!
- patrick
Thanks all
Call summary
Highlights
- Rpc Versioning:
- ·RPC team exploring endpoint-level versioning; seeking wallet feedback on backward compatibility requirements - 00:27:54
- Encrypted Mempool:
- ·EIP-8105 proposed as Hegotá headliner: encrypted mempool to prevent front-running via key providers - 00:54:05
- ·Two-step execution: gas payment in block N, decryption and execution in N+1 - 00:55:26
- ·Wallet changes needed: key provider selection, encryption flow, double signing, two-block confirmation tracking - 00:56:06
- Clear Signing Proposal:
- ·Kalapaja proposes on-chain clear signing with cryptographic commitment to display metadata - 00:32:10
- ·Solution uses 'clear call' wrapper (~7-8k gas overhead) validating display hash on-chain - 00:36:30
- ·Push-based semantics work without real-time dependencies; supports offline hardware wallets - 00:38:50
- ·Composable design enables multi-sig wrappers without additional hardware wallet integration - 00:42:16
- ·Live demo shown: dApp→mobile wallet→hardware device via NFC with native view rendering - 00:43:30
- Erc7730 Structured Data Signing:
- ·ERC-7730 draft V2 ready for public review; JSON metadata enriches ABI for human-readable transaction display - 00:09:30
- ·7730 file has three sections: context (contract binding), metadata (contract info), display (formatting rules) - 00:18:27
- ·Registry governance under discussion; migrating from Ledger GitHub to Ethereum Foundation soon - 00:24:41
- ·Audit/verification system for 7730 files needed to prevent malicious contract misrepresentation - 00:25:01
Action Items
- •Wallet developers - Provide feedback on ERC-7730 draft V2 in discussion thread or Nexus group - 00:26:46
- •Wallet developers and RPC consumers - Review RPC versioning PRs and provide feedback on backward compatibility pain points - 00:29:49
- •Wallet developers - Review EIP-8105 and provide wallet integration feedback to Shutter team - 00:57:05