Comment by earlz | Hacker News Reader

Comment by earlz | Hacker News Reader

Parent Full thread

As a hater of the EVM and person directly trying to replace this shit, here is my rebuttal:

First, smart contracts don't have a private key, at least not in the meaning of the word. They do the equivalent of signing by sending a message from their address to another address, or expose a function to indicate that a particular message is authorized by the contract code... but it's impossible to send some packet of data to a contract and (without external communication) have it verify "this data was provably sent by this contract"

Every other system I know of puts contract addresses in some other different namespace. Even looking at Bitcoin, they use the "3" address version for pay-to-scripthash, while "1" is for pay-to-pubkey. Internally Ethereum actually DOES namespace these two different address types implicitly. A normal address has no code and has a public key. A contract address has code and no public key. There are many many if-statements with this logic to handle the multitude of edge cases that come up from using the same address namespace for person-addresses and contracts... and beyond that, this has been the direct cause of several smart contract bugs because checking if a sender is person or contract is not trivial. Even for your purported benefit of being able to send coins to contracts in the same way as a person doesn't really work. You must attach some data when sending to a contract, whereas sending to a person should never contain data.

And for your idea of a contract having multiple addresses, what would be the purpose of this? Technically this is possible but not exposed today by making it so that an address contains both the location of a contract in the blockchain as well as encoding some data. Could be done simply by allowing an ethereum address to have more than 160 bits. The first 160 bits is contract address, the remaining is data to send to the contract.

I can understand Ethereum's design being not great. It was the first one to exist and the designers were not fully aware how it would be used.. but I will never understand the people that defend the design as "oh you just don't understand why this is a good thing"

> oh you just don't understand why this is a good thing

That wasn't my intent at all. I don't think it's a good thing; I just think it's a predictable thing. I was trying to justify it like you'd justify the actions of someone with a mental illness, or like you'd justify an evolutionary adaptation. To "feel the flow of the causal process that resulted in this" (which isn't just the designers not being "fully aware of how it would be used.")

Most people, I find, who are put off by Ethereum's design, don't actively dislike the design; they just find it hard to understand the motivation for its design decisions, finding them obscure. That's what I was trying to help with, there.

It's perfectly okay to understand that motivation and then dislike Ethereum. I do too! (I haven't seen a genuinely good distributed-computation substrate yet, though. Have any recs?)

> There are many many if-statements with this logic to handle the multitude of edge cases that come up from using the same address namespace for person-addresses and contracts

Eh, that's more a fact of the implementations than the design, I think? You could theoretically treat every EVM CALL op as always executing bytecode, with regular addresses being wrapped in an ADT that, when asked for their bytecode, returns a zero-length string; and an EVM interpreter that, when asked to execute a zero-length bytecode string, does so successfully at a cost of zero gas. IIRC, there's nothing in the yellowpaper constraining them from writing the code this way. Whoever wrote the code is just a bunch of mooks who don't understand data-primacy and eliminating (cyclomatic) complexity.

> because checking if a sender is person or contract is not trivial

I'm not too familiar with what is and isn't exposed in Solidity, but at the EVM level, isn't that just 𝑒 ("the present depth of the message-call/contract-creation stack")? If 𝑒=0, a human (or a human/bot oracle) called you; if 𝑒>0, another contract called you.

> And for your idea of a contract having multiple addresses, what would be the purpose of this?

There really isn't a legitimate purpose in a contract having access to multiple [pretend-]signing identities, given that you can always construct a system of contracts that message one-another to accomplish the same task.

The point of my thought was to achieve parity between smart-contract oracles and human/bot oracles, insofar as human/bot oracles can sit there and do things in response to anything happening on the blockchain they're watching, not just something happening to an address they own. Theoretically, contracts could be allowed to subscribe to any log event stream that a node can subscribe to, such that, after any 𝑒=0 call which generated logs successfully returns, the EVM would then be required to run all contracts with active subscriptions that match the logs just written into a transaction receipt, with those contracts paying the gas out of their own accounts to run.

Reply on news.ycombinator.com