3 ms·
You still need to think of what's inside the module and how it behaves. It's nice that a contract allows you to, say, kill an attempt at denial of service that
by alricb 11y ago
You still need to think of what's inside the module and how it behaves. It's nice that a contract allows you to, say, kill an attempt at denial of service that messes with the parser, but it's better to make your parser resistant to denial of service in the first place.
In fact, at the design level, you need to consider making whatever language you'll have to recognize as simple to handle as possible, with a recognizer that has the least computational power possible.
In a real application example, it would be great to isolate the ASN.1 parsing in TLS in some sort of prison, guarded by ruthless guards charged with blowing the parser's brains out if it so much a looks the wrong way. But it would actually be better to use a language that can be parsed with a simpler automaton that is more amenable to verification and inspection, because even if you hold a gun to its head, the parser can still give you the wrong answer.
- lmeyerov 11y agoIf someone is running verifiers on the contract language, or worried that their policies are wrong, they can restructure the underlying code or the policies. You're assuming the only verifiable things are parser languages from the 70s.
- alricb 11y agoIn many cases you just have to parse stuff (using a recognizer). If you want to verify that your parser is, in fact, parsing the right way, then you have to look at it formally.