Hard Problems in Cryptocurrency: Five Years Later

Re:Hard Problems in Cryptocurrency: Five Years Later by MuncleUscles on Sunday November 24, 2019 @05:06AM (#21619437)

Smart contracts are a bad paradigm for developing applications on the ledger, they're far too permissive, the stakes are too high to want to trust your assets to arbitrary turing-complete code.

You can do much better with composable state machines, because everything you do gets the same level of security as the native token transfers https://www.radixdlt.com/post/radix-engine-a-simple-secure-s...

Disclaimer: I work at Radix

[ Parent | on HN ]

Re:Hard Problems in Cryptocurrency: Five Years Later by yodsanklai on Sunday November 24, 2019 @12:00PM (#21621642)

> the stakes are too high to want to trust your assets to arbitrary turing-complete code.

Does it matter whether the language is turing-complete or not? you're trusting a contract, not the PL used to write the contract, and the contract can be very simple (and formally verified, if the PL has a formal semantics).

[ Parent | on HN ]

Re:Hard Problems in Cryptocurrency: Five Years Later by ddrdrck_ on Sunday November 24, 2019 @02:36PM (#21622736)

I think the point is that it is easier to formally verify a non-Turing-complete PL

[ Parent | on HN ]

Re:Hard Problems in Cryptocurrency: Five Years Later by st1ck on Monday November 25, 2019 @11:32AM (#21629774)

Smart contract language doesn't have to be Turing complete. In 2018 there was a few related R&D projects, so I hope some of them are more mature by now.

[ Parent | on HN ]