Going to be in Ethparis, our team is considering different projects and one of the idea is similar to this. I would love to meet you there Ethernian. telegram @miaozc
I’d like to get in on a call about this as well. Can we set something up for all of us?
I’d like to join in too. A few colleagues and myself were thinking last week about being able to generate Dapp UIs (similar to Dapplets) based on specifications. A specification would indicate what input fields are needed, and what to do with the input values - i.e. what contract functions to call and in what order.
From a given specification, different wallet and dapp browser makers would be able to generate a UI according to their design ideas, but the functionality (i.e .what the UI lets the user do) will be the same in terms of interacting with the blockchain.
The idea mainly revolves around making it easier to access smart contracts without having to build a full blown dapp.
I really like that idea, I was exploring a similar approach with the product I’m currently working on:
It’s providing an easy to use web GUI for smart contracts that could be used as a standalone website or an embedded widget.
Here’s the design file:
I have talked about this during Web3 Design Call.
I’d be happy to collaborate on this one and/or share insights and ideas.
Sadly no there this week. Perhaps we can do a call sometime?
moved the discussion into the Wallet Ring as the most appropriate, IMHO
I’m glad someone’s working on this! Micah and I started (but ultimately put on the back burner) similar efforts with trustless signing.
If you structure this correctly, there’s no reason that the ‘dapplets’ need to be trusted or audited. It helps to analyse the threat models for transaction signing:
- An attacker attempts to get you to send a transaction to a non-malicious smart contract, while lying to you about what it does. Eg, Alice tries to get you to send her all your cryptokitties.
- An attacker attempts to get you to send a transaction to a malicious smart contract they control.
Attacks using the latter are very limited; the only one that I’m aware of is convincing you to send your Ether to a contract the attacker controls.
Meanwhile, in the former case, the contract the transaction is being sent to can be trusted to correctly identify/explain its own transactions.
As a result, a model along these lines should work:
- Transactions can be explained using some kind of DSL. Inputs are the ‘dapplet’ for the contract, and a dictionary of data whose contents is determined by the dapplet. Outputs are a human-readable explanation of the transaction, and an encoded transaction object.
- Each supporting contract has a
isValidDapplet(bytes32)method, which takes the hash of the dapplet and returns true iff it’s an accurate description of the functionality of the dapp.
- Contract identities are verified - eg, using ENS - so people are aware of what contract the transaction is asking them to interact with.
I think we should better talk about trust chains than about trusted/untrusted. Audit is essentially only the point where the trust chain starts.
In particular the EIP-719 trustless signing is not completely trustless. It has the same trust origin as the contract and because of that it should be audited as the part of the contract.
Dapplets can root their chain of trust in the contract like EIP-719 does, but there are other ways to establish it, like an external audit made later by independent trusted party.
For more detailed answer I need few days more to understand objections and concerns to EIP-719. I’ll write later.
However you want to phrase it, my point is that you don’t need to audit a ‘dapplet’ for accuracy independent of the contract, as long as the contract vouches for it.
now fully agree.
Nevertheless the contract is not only the one (and should not be!) who can vouche for dapplet.
I have wrote a medium article (currently in draft):
I would really appreciate your opinion and critic before publishing.
A Tg group is here as well: “Dapplets and Secure Signing"
RE: the Dapplets Medium article Part 1.
Love the use of CRAZY.
This is a great intro, especially the summary, it really gets it across. The one thing I feel it needs is more about implementation, e.g. what does a dapp developer need to do? What does wallet developer need to do? How do these parties come to an understanding? I suppose this is for Part 2.
Still, might be good to briefly describe the basics.
Letting my mind wander a bit, this seems like a sort of UI EVM, and really only for the exact point of decision by the user.
The relevant information needs to be presented to the user, which includes an image. The action needs to be presented, in a way which is clear to the user. Certain dialogs also need to be incorporated, to represent the changing state or implications, or reflecting the status code (pinging @expede here).
These are not currently concerns at the contract level, and implemented in a hundred different ways and often terribly by dapp devs.
A standard can be created to enable this to happen at the contract level, a data structure which guides the UI of the action and immediate steps afterwards.
Then Metamask, wallets, mobile, and so on can render the result in a standard way, using WASM even to ensure consistency. I hope I am not repeating what y’all already know LOL.
I have improved the article accordingly.
I am unsure what do you mean by UI EVM? Is it the EVM or just some VM for the UI calculations?
My thoughts in that directions are DSL-centric. It seems to me we should define a DSL firstly and only then think about the VM executing the DSL.
This is my way too, definitely.
Anyway I would start with MVP for now. It will facilitate a broader discussion what the standard should look like.
RE: The “UI EVM”, I mean this conceptually! The dapplet constrains the UI of the final approval/signing process in order to ensure secure and predictable interaction with the user, and separates the final approval/signing UI from the rest of the potentially insecure UI of the dapp.