[nicksdjohnson]

If you want to know what a given transaction will do, you can simply run it locally; no need for formal analysis. Formal analysis is useful for proving properties about your program like "the total balance will always equal the sum of the accounts" and "transfers never increase the sender's balance".

[jude-]

I want to know what any possible transaction can do. See my sibling comments.

[nicksdjohnson]

But you can reason about what any possible transaction can do by reasoning about all possible inputs to your code; you don't need to know anything about how other contracts were written, since even if they are formally provable, they could send you literally any input.

Edit: Rereading your earlier comment, I understand now - you're talking about other contracts your code calls, not vice-versa. In that case, I'd point out that you're totally free to either write those contracts yourself if they're not already provably secure, or write your own code such that it's formally proved to work regardless of what those contracts do.

[jude-]

> But you can reason about what any possible transaction can do by reasoning about all possible inputs to your code; you don't need to know anything about how other contracts were written, since even if they are formally provable, they could send you literally any input.

I also have to reason about the transactions that invoke other smart contracts that, through one or more subsequent calls, will call into mine. These transactions are inputs to my smart contract as well. Recall that the DAO was hacked by an "attacker" contract that called into it, for example.

> I'd point out that you're totally free to either write those contracts yourself if they're not already provably secure, or write your own code such that it's formally proved to work regardless of what those contracts do.

If formal specification and verification were practical, we'd be doing it in every programming domain. Normally, few people bother since (1) it takes a lot of work, and (2) the consequences of bugs are small in most domains, especially compared to the consequences of not shipping code on time. If you have not tried to formally specify and verify the correctness of a non-trivial program before, I encourage you to try it before recommending that strategy (especially if that recommendation includes telling developers to rewrite other peoples' code).

Since smart contracts have other peoples' money attached to them, the developers' first priority must be user safety. Ethereum does not appear to take this seriously, since (1) its default programming languages are not designed to be amenable to formal verification, and (2) smart contracts are allowed to call into one another.

I would much rather program on a blockchain that kept smart contracts completely isolated from one another, and required me to submit a machine-checked proof that the user's money (1) will be sent to an address of the user's choice automatically no more than X blocks after the deposit, and (2) cannot leave the smart contract at an earlier time without a one-time-use signature from the user. If a smart contract cannot be proven to do both of these things, then the blockchain should prevent it from running.