4 ms·

Reading their blog about "smart contract security" [1] is just mind-blowing. Like, I thought that was the core of the product, but somehow they've designed a la

• jerf 10y ago
  Me from a month ago: "... having had a quick scan over the language documentation, it looks to me like a bog-standard imperative mutable language. One that is very young, and with few if any features designed for being used in a high-security environment. It appears to be based on raw event-based programming, a style of programming very easy to mess up and hard to declare and preserve invariants in. It looks like a very dangerous programming language to be trying to write financial contracts in. At least it's not dynamically typed, does seem to avoid excessive coercion, and should be memory safe; it could certainly be worse. But it could be better, too." https://news.ycombinator.com/item?id=11726734 https://news.ycombinator.com/item?id=11726734 I don't know off the top of my head what I would design into my contract language, but Solidity has numerous things in it that I would not. I guess in their further defense, the way I'd want to design the contract language is what is right now some really cutting edge programming language theory. I'd be looking very hard at the Total Functional Programming languages [1]. "Total" here is not just an enhancing adjective, it defines a specific characteristic of the languages with regard to how they terminate. But it still would have legitimately been research to figure out how to correctly convert from a programming language to its cost-to-execute correctly enough to be in a financial application. I believe TFP research right now is mostly focused on how to write TFP code that practically accomplishes things without having to write some pretty mathematically-complicated circumlocutions, not modeling costs. I also would have looked at doing something with FRP, not because it's the hottest new thing necessarily, but because the ability to express every participant's obligation in a single block of code like a thread rather than an event-based setup would have made these contracts much easier to write and audit. The combination of these two things is probably an entirely untouched domain, or at least effectively so. Ethereum is a fascinating idea. It's not hard to imagine something architecturally like it being huge in 50 years. It's not hard to even imagine it as the basis of cstross' unspecified "Economy 2.0" in Accelerando. But it might just be 5 or 10 years too early to work now. [1]: https://en.wikipedia.org/wiki/Total_functional_programming https://en.wikipedia.org/wiki/Total_functional_programming