27
28

I never read my contracts, do you? (self.ethereum)

Nooku が 投稿

The amount of contracts that I have signed in my life without reading them, is substantially higher than the contracts that I do have read. I never got into trouble with it, because most of these contracts had rules in case of rare events that never got triggered.

In this light, Ethereum contracts are more worry-some.

For starters, they are significantly harder to read, even for programmers it's harder to read code compared to reading one page of normal text. And the potential impact of Ethereum contracts are quite possibly much greater and more serious, because it involves your money directly without any chance to contest the result.

As a community, we might feel the incentive to rely on each other to double-check contracts. But if everyone is expecting the other person to check the contract thoroughly, we might eventually end up with a highly popular contract that is never double-checked by anyone.

My question to the Ethereum community is:

Are there any plans or projects that focus on this? Plans that focus on the readability of contracts, or focus on a community-driven checking of contracts.

Or do you think this is a step too far and we should stick to "this is computer code, and everyone's own responsibility".

Happy to hear all of your thoughts on this.

全 24 件のコメント
並べ替え:
トップ (提案されたアイデア)
ベスト新着論争中古い順Q&A

[–]mcgravier 16 ポイント17 ポイント  (3子コメント)

You usually don't check if your software is properly written, or if hardware (like processor or random number generator) is properly designed. In such cases you rely on reputation of manufacturer, and, in some cases, on third party certification, and I think in case of smart contracts things should look similar

[–]soylient 1 ポイント2 ポイント  (1子コメント)

I think somewhere down the road people could create security firms for the sole purpose of verifying the security and function of a contract. The process goes something like this:

  • A developer pays the firm for the audit and sends them the current version of the contract with the details on what the functions are.

  • The security firm audits both the security (looking for bugs) and the design to make sure it does what it's advertised to do.

  • If it passes the audits, the firm will create a certificate on the blockchain (so everyone can see it) to show that the version of the contract has passed their tests.

There's probably a lot of money to be made in this, especially after the DAO disaster. Developers will want to show that their contracts have been verified by multiple reputable firms so that users can rest assured their ETH and data are safe with their dapp.

[–]Owdy 1 ポイント2 ポイント  (0子コメント)

I've said this before, but I still think that one could build a decentralized bug bounty/prediction market for smart contacts. People would vote on it having a bug or not. If you were to find a bug, you could make it public and stand to win a lot on the market by betting against everyone else.

This would go hand in hand with decentralized insurance that could be used to insure contracts that have high enough "no bug" predictions. People could pay a small fee to use those whitelisted contracts to be covered by insurance if anything were to go wrong.

[–]merton1111 0 ポイント1 ポイント  (0子コメント)

No, you rely on the fact that if everything goes wrong, you can talk to someone to get everything return to the way it should have been.

[–]null0pointer 6 ポイント7 ポイント  (1子コメント)

As long as someone you trust has reviewed the contract and published a checksum it would be a lot easier for the average user to protect themselves. Although ideally everyone would do their own due diligence.

[–]xeroc 3 ポイント4 ポイント  (0子コメント)

That worked great for THEDAO ..

[–]chainsaw77 5 ポイント6 ポイント  (2子コメント)

Would it be possible to pair a developer and a lawyer and have a lawyer write out a legal contract stating how the smart contract is "supposed" to work. Then if a bug or exploit is used on the smart contract, there would be a legal contract to fall back on?

[–]Pouf5 1 ポイント2 ポイント  (0子コメント)

AKA Formal Verification.

[–]renegade_division 0 ポイント1 ポイント  (0子コメント)

Moax (prev known as Eris Industries) proposed something like that https://monax.io/explainers/dual_integration/

[–]CBobRobison 4 ポイント5 ポイント  (0子コメント)

I remember Drummond Reed citing a stat, which was something to the effect of: it would take the average person 300 years to read all the user agreement contracts they click through in a lifetime.

Golem currently has a formal solution for their microservices platform, which could solve this problem and be modeled in Ethereum: Developers publish their code to a registry. Then validators audit the code, either whitelisting or blacklisting the microservices. Workers (who get paid for running the the code) can then subscribe to validators' whitelist/blacklists for a fee. Validators earn these fees and develop a reputation for accurately listing code.

[–]chejazi 2 ポイント3 ポイント  (0子コメント)

There is a lot of effort going into formal verification to ensure contracts perform as expected, however it seems we're still in the early days: https://www.reddit.com/r/ethereum/comments/4uu9fb/formal_verification_for_solidity/

[–]3esmit 1 ポイント2 ポイント  (0子コメント)

The traditional contracts are too hard to understand, but ethereum contracts are easier. I am more capable of understanding an ethereum contract than a lawyer contract. I'm not a lawyer, I'm a programmer. Sure, I failed once at reading a contract since I never imagined was possible to do recursive calls, but now I'm aware of that.

[–]Dunning_Krugerrands 1 ポイント2 ポイント  (0子コメント)

Transaction Attestation Protocol Human Friendly Smart Contract Transactions

http://tap.dappbench.com/

https://medium.com/@petkanics/lets-talk-about-ethereum-transaction-transparency-a5a0d38ec1b5#.rib1s0ptu

[–]bobsummerwill 1 ポイント2 ポイント  (0子コメント)

I imagine that much of the gap here will eventually be filled by reputation systems, user ratings, insurance, paid auditors, etc.

It is utterly impractical for every individual in the world to review all of the smart contracts which they are party to, but by having them globally visible and immutable, this kind of mutual "review apparatus" can be built. I imagine that you'll end up with common libraries of "known good" components, and you'll end up with well-known solutions for common problems.

Trusting lots of money to a "novel" contract won't magically become safe just because it is a smart contract.

If you are buying a house, for example, I am sure that you will still want professionals to guide you through the legal process, even if their job becomes a lot easier in the future because of smart contracts.

[–]DeviateFish_ 0 ポイント1 ポイント  (8子コメント)

Well, provided you have access to the source code of the contracts, it's pretty easy to write your own suite of tests (or have someone else write them) to prove that the contract does indeed do what it says it does.

[–]killerstorm 0 ポイント1 ポイント  (7子コメント)

...and solve the halting problem while you're there.

[–]mcgravier 2 ポイント3 ポイント  (1子コメント)

As far as I understand issue, halting problem is quite theoretical - it would require infinite gas limit. In prctice it should be possible to test contract for very high, not practically achievable gas limit.

[–]killerstorm 2 ポイント3 ポイント  (0子コメント)

Your understanding of the halting problem is too narrow. One of its consequences that is that automatic verification of sufficiently complex programs is impossible.

It's not really about halting. For example, you might ask a question "Does this program ever output 42?", and that would be exactly as hard as the halting problem.

Or you might ask: "Does this Ethereum contract ever reaches state S?".

Gas limit is really irrelevant since state is preserved across contract invocations, and commonly you care about the final result of such invocations.

E.g. suppose there is an Ethereum program with a single externally callable function run() which might call internal function payout() which sends money to you and sets state variable halted to true. If halted is true then run() will throw.

You have a chance to be paid by this contract if and only if the following program halts:

while (not halted) {
  run();
}

So if you are able to tell whether you will be paid you can also solve the halting problem.

[–]DeviateFish_ 0 ポイント1 ポイント  (4子コメント)

I get that you're trying to be snarky, but really, this is a stupid comment.

Hence having arbitrary people writing the tests. Because you know, it isn't exactly hard to write tests that include contracts capable of exploiting the contract in question, etc.

[–]killerstorm 1 ポイント2 ポイント  (3子コメント)

You're either too snarky or too ignorant.

If it was so easy, why did it took people several problem to discover the DAO hack?

You can write tests for sufficiently simple contract, but if it's complex, the number of possible states/call combinations/etc becomes too large to test (like, exponentially large), and automatic verification isn't going to help either.

[–]DeviateFish_ 0 ポイント1 ポイント  (2子コメント)

You're either too snarky or too ignorant.

Probably the former.

If it was so easy, why did it took people several problem to discover the DAO hack?

Because honestly, the vast majority of "Solidity experts" in the space are pretty amateur at coding. As I've explained elsewhere, the DAO bug was simply a race condition (not a data race!). The lack of basic programming understanding (e.g. that race conditions exist) and a lack of a security-minded focus/review on the part of the authors.

Protip: it never actually went through a code review. There was a small bit of code review in one case, but before they really dove into the code, CJentzch joined and turned it into a sales pitch. You don't have to take my word for it, but it'll be an hour+ slog through a halting hangout to come to the same conclusion.

You can write tests for sufficiently simple contract, but if it's complex, the number of possible states/call combinations/etc becomes too large to test (like, exponentially large), and automatic verification isn't going to help either.

This is only true for things that lack sufficient encapsulation. If things are properly encapsulated, it doesn't matter how large the contract gets--verifying it stays a linear-ish problem. A properly-encapsulated piece can be tested in isolation, and it can be easily verified that it does what it's supposed to do in all cases. If each piece does what its supposed to do in every case, various combinations of those pieces will also do what they're supposed to do, in every case.

Complexity only becomes a problem when things aren't properly segregated from each other/global state is abused/etc.

[–]killerstorm 1 ポイント2 ポイント  (1子コメント)

Because honestly, the vast majority of "Solidity experts" in the space are pretty amateur at coding.

Dunning-Krugermeta ?

the DAO bug was simply a race condition

You're right that this bug isn't in any way unique to Solidity. But you're wrong calling it "race condition". There was no race, the behavior is 100% deterministic, and there is only a single thread of execution.

The actual problem was a lack of re-entrancy in TheDAO function(s).

The lack of basic programming understanding (e.g. that race conditions exist) and a lack of a security-minded focus/review on the part of the authors.

Yeah, I'm sure people writing VMs, compiler and network servers lack "basic programming understanding". LOL.

[–]DeviateFish_ 0 ポイント1 ポイント  (0子コメント)

You're right that this bug isn't in any way unique to Solidity. But you're wrong calling it "race condition". There was no race, the behavior is 100% deterministic, and there is only a single thread of execution.

Race conditions in no way require multi-threading or parallelism. You're thinking of data races.

Race conditions are simply executing of instructions in an order that you don't expect them to be executed in. Recursion can be used to trigger race conditions.

The actual problem was a lack of re-entrancy in TheDAO function(s).

Which, again, is a subset of race conditions.

Did you even read the thread I linked? I understand how this works far better than 99.9% of the people in this sub--especially considering I'm the only one to have published something outlining 2 additional vulnerabilities in the DAO, including the one that could have been used to save/burn the stolen ETH without the need for a hard-fork.

But what do I know.

Yeah, I'm sure people writing VMs, compiler and network servers lack "basic programming understanding". LOL.

You realize that's about 5 people in the entire Ethereum ecosystem, right? None of whom formally (or informally) reviewed the DAO code at all? None of the authors have been involved in writing any core code of literally anything in the Ethereum ecosystem.

[–]akalaud 0 ポイント1 ポイント  (0子コメント)

The contract is not important to me, but the functionality is. What will it do for me, how long has it been used, what reputation does it have in the community. Then I can trust and use it without reading the contract.

I do the same when I open a credit card account, if it's from a reputable company, I just sign.