Hacker News new | ask | show | jobs
by albertgoeswoof 2972 days ago
This idea is obviously stupid but it really does expose the missing consistent, friendly front end experience for dApps. I have no idea what contract this is pointing to and what happens when I submit the transaction. MetaMask tells me some info but very little really. I don't know which buttons are going to trigger a MetaMask prompt and start an on chain transaction and which point to a centralized backend etc.

Compare that to the web where I know underlined text takes me somewhere else, hover over will give me the URL, there are standard browser components for input fields, buttons etc.

I'm really hoping there's a drop in framework for this which reaches mass adoption soon.

4 comments

We've been trying to tackle this at Hexel. We recently launched our own wallet and Discord integration so that you can send coins for free, to any email or Discord user. You can link your token to your Discord server and let anyone send it via chat. This makes it easy to actually use your token after creating it, and no MetaMask is required for most users (everyone except the token creator).
Is your wallet code open source? How can a user verify that the token is safe, and won't be easily hacked.

P.S. I understand that most tokens don't have much monetary value, but just wanted to understand the benefits and legal ramifications of taking on a custodial wallet...

Good stuff!

Discord is a private proprietary service, right? Why did you choose to solve distribution over that instead of something more widely used, like the web?
Discord is just an integration we offer. We also have a web wallet that lets you send tokens to anyone by email or username.
They obviously tackled the right crowd. Most of 'get rich quick' Ethereum discussions is happening on discord right now.
It's not pointing at a contract. Metamask should let you view the data (and it they're working on it[1]), but ultimately if you want to verify the contents of a contract you're deploying you'll have to compile it yourself. I suppose metamask could take the source and compile it for you, but ultimately verifying what a transaction is going to "actually" do seems like a difficult problem that's unlikely to be solved anytime soon.

[1] https://github.com/MetaMask/metamask-extension/issues/2847

It says:

> When you fill in the details and click create, MetaMask will ask you to confirm the transaction

> Check if you're ok with the ethereum transaction fee and click submit.

In this case it's creating a new contract (I didn't notice the "new contract" logo in MM at first glance). I have to dig into the FAQs to find the source for that contract, and as you point out MetaMask can't guarantee that's the actual source. So this is an easy opportunity to stick a backdoor in that can hijack your created coins at any point.

A better approach would be to call an existing contract on the blockchain which creates a new contract from it's own source. Is there a reason not to do this?

It still wouldn't solve the problem of viewing the source. You can't easily view the source code of a deployed contract. The only way to verify a contract is to find the source code from somewhere, then try compiling it and check if the bytecode matches the blockchain data. But details like compiler version and compiler flags may lead to the bytecode not matching.

In short, there's no good way of verifying an ethereum contract.

But that can be automated though, right? You could post the source on IPFS or some hosted provider, put the hash inside the source code on chain, and have MetaMask or whatever is calling the contract download, compile and compare the code?
metamask could peek at etherscan and see if a contract has 'verified code' or not. often times, contract creators upload the source code to etherscan itself to get the verified badge https://etherscan.io/address/0xd22f97bcec8e029e109412763b889...

however, that would require trusting etherscan, but metamask already relies on it pretty heavily, so...

if the user didn't want to rely on etherscan, it's possible to have metamask verify contracts itself - the dapp publisher would need to provide the source with the dapp, metamask could compile it, and make sure it matches the on-chain bytecode. i believe solc is written in javascript so it would be possible to ship it with metamask.

i'm not sure how this would work with contracts with dependencies. at that point, the sources of all the dependencies would need to be verified. this would require larger infrastructure (e.g. etherscan, but again, a single point of failure).

in that case, it would almost make sense for another data section in the EVM to hold the contract source. in this case:

* 1. contract source code is all stored on chain, in a decentralized manner

* 2. clients can verify the byte code

* 3. it's more expensive to publish a contract since it needs the extra space to store the source

On #3, I suppose that's the difference between OSS and closed source software today.

But why not just store an IPFS / Swarm hash linking to the source on chain? That requires almost no cost overhead per contract.

Why would that be better though? How are you going to verify the contract that the deployed contract is deploying? How are you even going to verify what message you're sending to the already deployed contract (assuming the user isn't technically knowledgeable). You can have a third party (etherscan for instance) verify the contract after it's deployed. My main point here is that this is a complicated system, and there's only so much somebody who doesn't really understand the basics can be protected from it.

Even the web example you gave isn't as simple as it first appears. Just because you fill in a form with certain details doesn't meant that's what the page is actually sending to the server. Most of the time this isn't an issue, as you "trust" the page you're on not to fuck around.

> Even the web example you gave isn't as simple as it first appears. Just because you fill in a form with certain details doesn't meant that's what the page is actually sending to the server. Most of the time this isn't an issue, as you "trust" the page you're on not to fuck around.

This is what blockchains bring, you don't have to trust the web page any more. With a dApp you know exactly where that form is going and what's going to happen, with the web you only know a POST request is outgoing somewhere and hopefully it'll be handled correctly. It's not something that's easy to understand yet, but one day it might be.

> How are you going to verify the contract that the deployed contract is deploying?

Go and look at it, compile + compare the source etc.

found the dApp comment. question-

Anyone actually find a usecase for public, decentralized, verified ledgers?

Like I dont understand a use-case. Currency is basically solved by bitcoin.

After that, I dont see why you wouldnt trust a single source? Most things like social media, videos, medical records, etc... dont need to go through the blockchain. They can be centralized.

Anyway, asking this question here, because on reddit its awful.

Any programmers actually finding blockchain is going to be another tool for us to use? Or is it all hype and niche use-case?

Actually, if you scroll down there's an explanation of what will happen when you click create. Perhaps it would've been better to add a tooltip on create.

But generally I agree, it's hard to design UIs in crypto, having to install and use a plugin like MetaMask doesn't add to the trustworthiness of the site.