[warbiscuit]

Oh, I definitely think they can. Didn't mean to imply otherwise!

I do think the surface area for attack is much more limited, since the code is innately public (unlike centralized trading houses).

That (in theory) should make them more secure, particularly if considered in terms of the transparency provided. I also think theorem proving, and languages amenable to it, can greatly reduce the surface area even further; reducing it down to a matter of reviewing what assertions the theorem prover was handed, along with trusting the VM's implementation itself. (The later is also helped by having multiple independant implementations).

But I don't think the tech is there yet. The languages currently being used aren't the greatest for theorem proving; no one's actually done much of that in practice anyways; there aren't "best practices" for upgrading your smart contract when a bug is found; and there's ALWAYS an assertion someone forgot to add to the test suite.

But I do think smart contracts could remove "server compromise" and "unauditable code" from the list of main dangers of an exchange, which does seem quite useful in the long term (once the ecosystem fleshes out a bit).

[warbiscuit]

Followup just to clarify: The reason smart contracts drastically mitigate "server compromise" is that compromising / altering the operation of the VM (and not merely exploiting a bug) requires a 51% attack on the entire network. That should generally be a MUCH more expensive undertaking than the value of any given smart contract (under the assumption that the network will be valued at least 2x more than any of it's participating apps).

[empath75]

You don't need to implement a 51% attack to hack a smart track, as evidenced by the dozens of smart contracts that have been emptied out on ethereum.