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
2 Likes
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.
1 Like
Hello!
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:
https://www.figma.com/file/P6G4CuHmVGKZVdR9JQ5GStx9/Dappi-product?node-id=0%3A1
I have talked about this during Web3 Design Call.
I’d be happy to collaborate on this one and/or share insights and ideas.
2 Likes
We are in WTHParis. If you are here let us talk and buidl.
CC @patrykadas
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.
3 Likes
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.
1 Like
now fully agree.
Nevertheless the contract is not only the one (and should not be!) who can vouche for dapplet.
Guys,
I have wrote a medium article (currently in draft):
I would really appreciate your opinion and critic before publishing.
Dapplets (part 1): introduce new Dapp architecture for better UX and security
Thank you!
A Tg group is here as well: “Dapplets and Secure Signing"
1 Like
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.
1 Like
Hello, Jamie!
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.
1 Like
I have published the medium article:
Dapplets (part 1): introduce new Dapp architecture for better UX and security
1 Like
Generally I am fine to implement the most restricted version first, but what is the advantage of the restriction?
yes, you are completely right.
If the TheGraph/Fluence service provides no cryptographic proof for response (the situation right now) or can’t be trusted in some other way (like node ownership), dapplet should make a web3 call instead.
I am not against web3 calls generally. I have just proposed a way to work with existing legacy sites built without any web3 support in mind.
The second aspect: the web3 in its current state is damn inefficient for querying blockchain data. But if web3 will have efficient querying facility like TheGraph/Fluence, why not use it?
Another aspect is the trust: there is no sense to use web3 to create sensitive objects like transactions in such generally mistrusted environment like dapp and the browser.
May be it was a little bit exaggerated to say “don’t use web3 in dapps”.
More nuanced message could be: it is more efficient to replace web3 reads with TheGraph-like service and move web3-writes to the signer; may be you will not need the web3 dependency in your dapp at all.
agree: audit is pluggable and out of scope of the architecture. Nevertheless the infrastructure should offer the way to check the audit status and the trust path, thats why I have mentioned it in the article.
“The same domain” policy is not only the way to create the trust: dapplets may be created by 3rd party and should not need any allowance from contract author to operate properly.
I have used words like “recover” or “guess the View” to describe what the Wallet/Signer generally should do in order to display the binary transaction correctly. May be the wording doesn’t fit exactly to EIP-719, but essentially it doesn’t matter: it is not about how the Signer does it technically (“reverse engineeriring” or “querying the method registry”). It is about how secure, how informative and how flexible it is.
IMHO, an EIP-719 is quite secure, but could be more flexible (supporting other view verification sources than the contract) and more informative (supporting images or additional context parameters).
It’s easier for clients to implement, and it’s more secure.
I really think this is orthogonal to what you are trying to achieve.
My point is that 719, iirc, doesn’t do either of these things; it uses the same kind of interface you’re proposing for dapplets, where the data format passed to them is application specific.
1 Like
Yes, it is. But why are you mentioning this?
Is there more than “It does not belong to the standard itself, but important for standard adoption”?
I’ve got an idea of Dapplets independently from EIP719 and become aware of it later from people’s feedback. I see similarities and consider the EIP719 as one of simple ways to implement an initial version of Dapplets. Nevertheless the scope is Dapplets is broader, so I see EIP719 as a possible part of it, not as replacement.
Disclaimer: I have to read and think about EIP719 deeper in details. My understanding of it is still not complete.
Smaller standards are generally better, and more likely to get reviewed and implemented. And separation of concerns is good too.