|
|
|
|
|
|
by jt2190
1664 days ago
|
|
|
> ...instead focus on getting the code correct the first time This is a threshold that real-world contracts don't typically have to achieve. They leave lots of details out, or vaguely defined, because the odds are low that that part of the contract will have to come into play, and it's not worth the extraordinary effort and time and expense to negotiate every tiny very-unlikely-to-happen case. To quote Lawrence Lessig [1]: "Often obscurity is a real value. Obscurity is what you want... In principle we should be negotiating all of these [possible things that could happen to our deal]... What contracts do all the time [instead] is they create these fuzzy or vague or ambiguous places as a gamble... And if it turns out [that this .002% occurrence does] happen, we'll ask... a judge to figure them out. Also, if you're just going to replace one immutable contract with another, you're back to meatspace and re-negotiation, which can be time consuming and expensive. [1] MIT 15.S12 Blockchain and Money, Fall 2018. "Smart Contracts and DApps" https://youtu.be/JPkgJwJHYSc?t=3543 |
|
|
And boy does it show!
How do you debug your smart contract? Your users tell you their money got stolen out of it. I wish that was a joke.
> Also, if you're just going to replace one immutable contract with another, you're back to meatspace and re-negotiation, which can be time consuming and expensive.
Is upgrading them in place somehow better? At least by keeping the old systems around, the people who still get mileage out of them aren't sold up-river.