remains astonishing to me that there’s no real way to know what an eth transaction actually does before signing it, and the ecosystem is basically fine with this
87
100
862
Conversation
You can't just run it on a private fork of the chain and see? I know nothing about this junk but that seems like how it "should" work..?
1
2
For Bitcoin, the flow is almost always generating a transaction with your wallet. There are only a small set of operations which can be composed to implement straightforward things. For example, Lightning channels are simple 2-of-2 multisig with a timelock setup for recovery.
1
2
In some cases, for doing multisig with multiple wallets, you would be generating a partially signed transaction fully understood by each wallet involved.
For both multisig and hardware wallets, it's important that it's fully understood and displayed by the UI for confirmation.
1
Ethereum has complex arbitrary code with loops, method calls and interactions across contracts. The wallets for working with Ethereum have no idea what they're approving. Users have no idea what they're actually approving and it's pretty easy for all their stuff to be stolen.
1
2
The flow for a Bitcoin wallet is generating a transaction based on what you want and then confirming it. For a hardware wallet, you're required to confirm the destinations/amounts, fee, time lock configuration, etc. and it won't sign what it can't understand and show to you.
1
2
Flow for Ethereum is authorizing a web site to interact with your wallet, web app generates code and you blindly sign a transaction using that code with no clue what you're actually doing. This is how they end up in the "all my apes gone" situation even with a hardware wallet.
1
1
5
It's not simply that people don't understand the code of contracts involved. They don't understand how they're interacting with them. Even if the contract is bug free and not malicious, wallets don't know how to interact with it and don't understand what they're approving.
1
1
4
The programs have state and often depend on lots of external state. Their results can be very subtle. Simulating it and then using a domain specific viewer to inspect results would have a lot of issues. It would likely catch some low hanging fruit but it's not a viable solution.
1
4
This Tweet is from a suspended account. Learn more
It would have been entirely possible for them to define heavily scrutinized standardized contracts for handling things like their JPEG tokens where each one uses the same code. Wallets could have specifically supported those, not signing externally made code for arbitrary things.
Ethereum IS pretty broken and the ecosystem around it is even more broken. It's the culture of quickly hacking together security critical code and trusting all this poorly understood/scrutinized code from others that's most broken. Tooling also makes C look like a safe language.
1
2
Even without standardized contracts they could have had a standardized declarative language scoping what the txn can do that your UI can present to you. Kinda like shipping a sketchy binary along with a seccomp filter it's supposed to run under.