15 ms·

Fe – An emerging smart contract language for the Ethereum blockchain

114 points by 0xedb 5y ago

Swizec 5y ago
> Decidability by limitation of dynamic program behavior This claim sounds suspicious. If the authors really solved this, they have a bright future. A turing award for sure.
- crvdgc 5y ago
  I don't know if it's the case with this language, but in general it is possible to limit the expressiveness of a language to achieve decidability. The language cannot be Turing complete of course, but for example, we can have a language with the same computation power as finite automata, which is Turing decidable, and sometimes enough for the use case.
- narush 5y ago
  If your willing to limit dynamic program behavior, then you get decidability pretty easily. As a really stupid, simple example, consider a programming language where you were allowed at most 5 lines of code, where each can perform operations on a single variable: incrementing or decrementing it. You’ll pretty easily be able to figure out if these programs terminate, all because you limited dynamic program behavior. With this language, it looks like: they force all dynamically-sized objects (any string, any array) to set a maximum size at compile time, and limit loops to be statically sized (or on the length of one of those static sized objects). It feels like this gets them most of the way. The missing bit is some reasoning about recursion: I didn’t look close enough to see what they do, but it seems like you could either disallow it (not great, but in the smart contracts I’ve written it’s not been super useful anyways), or you could do some sort of static reasoning about the recursive parameters to the function getting smaller (the gas accounting seems tricky here). IMHO, the hard part of this language is convincing anyone the compiler is totally bug-free. In as hostile an environment as a blockchain, where a single bug can lead to all your money going bye bye, using a “new” language is a risk most people will choose to avoid, unless there is a seriously good reason to choose this new language. IMO, decidability is not a killer-enough feature to convince people to take this risk.
  - nuclearnice1 5y ago
    Clarity also claims decidability. It gives up recursion and restricts looping. https://github.com/clarity-lang/reference/blob/master/reference.md https://github.com/clarity-lang/reference/blob/master/refere...
  - preseinger 5y ago
    You are trying to re-discover Turing completeness from first principles and apparently without the relevant theoretical background.
- ur-whale 5y ago
  Not sure decidability is that much of an issue for smart contract language. There's a game-theoretic argument that pretty much solves the issue: you pay money to run your smart contract. The more it runs, the more it costs, until you run out of funds (gas). Sounds pretty decidable to me.
  - whimsicalism 5y ago
    I agree but have no idea how that relates to game theory.
    - ur-whale 5y ago
      In theory it's possible to let your dapp run forever, hogging resources from the network and "breaking" the system. But that would cost you such a large amount of money that no one does it. In other words, the system, while breakable in theory, isn't in practice because of a set of economic incentives (or as it were, dis-incentives in this case).
- mgraczyk 5y ago
  All EVM programs that run on Ethereum are trivially decidable because of the per-block gas limit ;P
MereInterest 5y ago
Wait, the cryptocurrency community is going back to smart contracts? I thought the hype had died down there after (1) the DAO hack showed that smart contracts are nothing more than self-funded bug bounties, and (2) the founders using social pressure to override the DAO contract showed that smart contracts are just as vulnerable to human interpretation as any real contract.
- joefourier 5y ago
  They never stopped? Smart contracts have grown vastly more sophisticated since the old DAO, with flash swaps, decentralised exchanges, overcollaterised loans, bridges, NFTs, and more ERC20 tokens than you can count.
  - foxes 5y ago
    Has the added complexity had a corresponding increase in correctness?
- abaga129 5y ago
  Smart contracts are huge in crypto currency and are likely here to stay. Afaik all of the top 10 crypto currencies by market cap have smart contracts or plan to have them except bitcoin and tether. They power decentralized apps and defi. Without them then a blockchain doesn't have much utility aside from processing transactions.
  - emerged 5y ago
    Well to be fair, blockchain doesn’t have much utility with them either.
  - vimy 5y ago
    Bitcoin has smart contracts now.
    - ur-whale 5y ago
      > Bitcoin has smart contracts now. Mmmh, that's a little bit of a stretch. They're building infrastructure (eg taproot) with a goal to support them in the future. But doing ETH-like dapps on Bitcoin is nowhere near ready (or, if you listen to some Bitcoin folks, even desirable).
miohtama 5y ago
Another Solidity alternative is Vyper. It is statically typed, safe, Pythonic approach. https://vyper.readthedocs.io/en/stable/ https://vyper.readthedocs.io/en/stable/ https://twitter.com/vyperlang https://twitter.com/vyperlang Vyper is being used in Curve and Yearn (both billions of dollars of TVL): https://ethereum.org/en/developers/docs/programming-languages/python/ https://ethereum.org/en/developers/docs/programming-language...
- barkingcat 5y ago
  there are some significant issues about vyper that anyone using it would/should be aware of: https://blog.ethereum.org/2020/01/08/update-on-the-vyper-compiler https://blog.ethereum.org/2020/01/08/update-on-the-vyper-com... that’s not to discredit anyone using vyper, just that when putting “billions of dollars” in play on a project like this, you better have teams of folks looking into the security implications of using such a technology with known caveats that the ethereum foundation team publicised. now things may have changed in the meanwhile between the time that notice was published and now, but if you are using or recommending vyper, it’s worth it to ask or state explicitly “which” vyper and “which version” of vyper, or “did you fork vyper in order to fix some of the issues outlined in the audit” as well as “if you are using vyper in critical applications, are you contributing your fixes back to the community?” If some of the answers are "the ethereum foundation team are too conservative" "the audit doesn't mean anything" "we don't have anyone looking into the security aspects of vyper" then you have your answer: they're going to get hacked.
- ur-whale 5y ago
  > Another Solidity alternative is Vyper. Vitalik was pushing Vyper quite hard for a while, but he seems to have ramped that down. I wonder if Vyper is in any way better than Solidity. At any rate, smart contract languages have security / verifiability constraints that few other domain of application have, and I don't believe any of the current languages offer what is really needed (integrated formal proof of behavior of the smart contract).
  - barkingcat 5y ago
    The Ethereum foundation stopped supporting the project. You can read their notice on their blog I linked.
sfjailbird 5y ago
And still not a single example of a good real world use case. I would love to be proven wrong, but all answers to this question I have seen so far devolve into a bunch of self-referential babble that leaves you no wiser at the end of it. And I'm saying this as a fan of cryptocurrencies and someone who wants to see them succeed.
- number6 5y ago
  A good usecase: Shares as NFT. This would make Fraud like Cum-Ex and Cum-Cum impossible. https://en.m.wikipedia.org/wiki/Dividend_stripping https://en.m.wikipedia.org/wiki/Dividend_stripping
- yyyk 5y ago
  >And still not a single example of a good real world use case. Ransomware, tax laundering and a relatively safe method for organized crime money transfers are excellent use cases (just not 'good' ones).
- Tepix 5y ago
  What do you think about Initial Litigation Offerings? Link: https://medium.com/avalancheavax/initial-litigation-offerings-to-bring-10b-asset-class-to-avalanche-blockchain-retail-investors-2aff880fa641 https://medium.com/avalancheavax/initial-litigation-offering...
  - dmitriid 5y ago
    Bullcrap. Why? Any written contract can be reviewed and understood by a person. These contracts can be enforced by the use of the existing institutions. Where as something something tokens offering: - Contracts are written in an esotheric programming language that pretends to reflect a real-world contract - These contracts are unenforceable - And they still depend on some entity somewhere to enter correct info into the system. All that can be done and is being done by hundreds of companies without the use of bullshit tech.
    - sanderjd 5y ago
egberts1 5y ago
Fe? Iron-clad contract? Nice pun.
- cmer 5y ago
  My mind immediately went to Fee, which is quite fitting for Ethereum.
vertak 5y ago
To any Fe developers reading this: please put a non-trivial code snippet of Fe, with code comments that highlight the improvements over Solidity, front and center on the README. I am a longtime smart contract developer who has been burned by Solidity’s downsides so I am excited about new EVM languages. I’ve read the Fe README, the announcement blog post, and the Uniswap v2 examples, but still have no concrete set of improvements over Solidity that I can point to. Maybe it’s just because things are still early, but from 15 minutes looking at Fe it still seems like Solidity but this a Pythonic syntax. As a Solidity dev, I want to see concretely how Fe improves on my existing smart contract language. Thank you for pushing the frontier on smart contract development! I feel we’re in the very beginning of smart contract development and languages like Fe can be the path towards preventing tons of these hacks we see every week.
- wanderingstan 5y ago
  Seconding this. It’s a broader problem I find on open source repos where they bury or leave out the info a first time visitor wants: what does this thing do? Why is that better? What does it look like in practice?
- davesque 5y ago
  Fe founder here. I'm not currently actively working on the project and haven't been for a while. That being said, a useful bit of context is that Fe was also originally conceived as a response to Vyper. In fact, it used to be called "Rust-Vyper." Vyper was just like what you say; a python-looking smart contact language that didn't work much different from Solidity. However, it actually explicitly removed certain features in the name of security. I felt like some of what was removed was actually pretty useful and their removal might have actually decreased security (imports, multiple contracts per file, and so on). So some of what I felt Fe should do was just add those things back in. Vyper also had other issues such as (IMHO) its choice of implementation language which led to a lot of internal tech debt. Also, at the time I was working on Vyper, it actually used Python's standard parser library and so we often had to shoehorn language features into the Python syntax. Vyper may have corrected those things since then but I don't know. In any case, I eventually just decided to start over in my spare time using Rust as an implementation language. There was other work planned for Fe such as providing a "strict" compiler mode that would facilitate formal verification of contracts written in Fe (that was basically a goal of Vyper). Also, we planned to provide a thorough specification and semantics for the language also for that purpose. I believe a lot of those plans are still in place but the current team should probably comment. As you say, I think part of the issue is that things are still very early. The core devs are always figuring out useful things to add along the way that end up differentiating the language from its competitors. I'd say more but I'm on my phone :).
bob332 5y ago
Crypto is for absolute morons, stop wasting our time with such crap
mgraczyk 5y ago
For those not familiar with Solidity, there is a peculiarity in the "ABI" that makes it painful to interop between languages. In solidity, there are types called "contracts" which are like classes in other languages. When you call a function in a different contract, the dispatch is routed using the first few bytes of the has of the signature [1]. For example, to transfer ERC-20 tokens you dispatch using `hash(transfer(address, uint256))[:4]`, meaning that you put those first four bytes at the beginning of the data that you pass to the receiving contract. Just like the native world, this causes a problem when you try to interface between different languages. In Fe, the types have different names so this hashing scheme can't work without a translation layer. From some of the issues it looks like interoperability may be a problem [2]. That's ok if you write all the contracts that your dApp interacts with, but as time goes on dApps interact and call into one another more and more often. There are probably also lots of opportunities here for exploiting confusion at these boundaries, so if you're inclined and know how to use tornado you may be able to make quite a bit of money off contracts that use Fe. [1] https://docs.soliditylang.org/en/v0.8.10/abi-spec.html#function-selector https://docs.soliditylang.org/en/v0.8.10/abi-spec.html#funct... [2] https://github.com/ethereum/fe/issues/592 https://github.com/ethereum/fe/issues/592
- deleted 5y ago
  [deleted]
- davesque 5y ago
  Fe currently doesn't support the offending type and I'm pretty sure the rest of the types support the same names internally. Smart contact development isn't like native systems programming where the details of the ABI are not considered in the majority of work. I think any smart contact engineer worth their salt will immediately ask what hash will be generated by a given type and confirm that it's compatible with standard contract interfaces.
  - mgraczyk 5y ago
    Yeah looking at elements.rs, it appears that they have the translation layer I alluded to: https://github.com/ethereum/fe/blob/bfeffe82b4f8623330c1ebb1950ca981449c9e86/crates/abi/src/elements.rs#L95 https://github.com/ethereum/fe/blob/bfeffe82b4f8623330c1ebb1... It's not obvious to me though and I couldn't find documentation for ABI compatibility. For example, does delegatecall to solidity work? That requires that Fe also use the same "binary" layout for storage in which slot index is used to generate the storage hash: https://docs.soliditylang.org/en/v0.8.10/internals/layout_in_storage.html https://docs.soliditylang.org/en/v0.8.10/internals/layout_in...
Fire-Dragon-DoL 5y ago
I started studying Solidity recently and found that code sharing and reuse is done through inheritance. What's the reasoning behind this? I thought we have a lot of documentation about inheritance being bad, but in Solidity not only this is core, but multiple inheritance is also core. This is then combined with (occasional) implicit access to permanently stored data, and with something that I can only describe as function inheritance. While discovering this, I started having the thought that it was done on purpose (easy to find faulty contracts that could be hacked for money). This was a nasty thought, indeed, but I found a lot of anti-features.

114 points by 0xedb 5y ago

> Decidability by limitation of dynamic program behavior This claim sounds suspicious. If the authors really solved this, they have a bright future. A turing award for sure.

crvdgc 5y ago
I don't know if it's the case with this language, but in general it is possible to limit the expressiveness of a language to achieve decidability. The language cannot be Turing complete of course, but for example, we can have a language with the same computation power as finite automata, which is Turing decidable, and sometimes enough for the use case.
narush 5y ago
If your willing to limit dynamic program behavior, then you get decidability pretty easily. As a really stupid, simple example, consider a programming language where you were allowed at most 5 lines of code, where each can perform operations on a single variable: incrementing or decrementing it. You’ll pretty easily be able to figure out if these programs terminate, all because you limited dynamic program behavior. With this language, it looks like: they force all dynamically-sized objects (any string, any array) to set a maximum size at compile time, and limit loops to be statically sized (or on the length of one of those static sized objects). It feels like this gets them most of the way. The missing bit is some reasoning about recursion: I didn’t look close enough to see what they do, but it seems like you could either disallow it (not great, but in the smart contracts I’ve written it’s not been super useful anyways), or you could do some sort of static reasoning about the recursive parameters to the function getting smaller (the gas accounting seems tricky here). IMHO, the hard part of this language is convincing anyone the compiler is totally bug-free. In as hostile an environment as a blockchain, where a single bug can lead to all your money going bye bye, using a “new” language is a risk most people will choose to avoid, unless there is a seriously good reason to choose this new language. IMO, decidability is not a killer-enough feature to convince people to take this risk.
- nuclearnice1 5y ago
  Clarity also claims decidability. It gives up recursion and restricts looping. https://github.com/clarity-lang/reference/blob/master/reference.md https://github.com/clarity-lang/reference/blob/master/refere...
- preseinger 5y ago
  You are trying to re-discover Turing completeness from first principles and apparently without the relevant theoretical background.
ur-whale 5y ago
Not sure decidability is that much of an issue for smart contract language. There's a game-theoretic argument that pretty much solves the issue: you pay money to run your smart contract. The more it runs, the more it costs, until you run out of funds (gas). Sounds pretty decidable to me.
- whimsicalism 5y ago
  I agree but have no idea how that relates to game theory.
  - ur-whale 5y ago
    In theory it's possible to let your dapp run forever, hogging resources from the network and "breaking" the system. But that would cost you such a large amount of money that no one does it. In other words, the system, while breakable in theory, isn't in practice because of a set of economic incentives (or as it were, dis-incentives in this case).
mgraczyk 5y ago
All EVM programs that run on Ethereum are trivially decidable because of the per-block gas limit ;P

MereInterest 5y ago

Wait, the cryptocurrency community is going back to smart contracts? I thought the hype had died down there after (1) the DAO hack showed that smart contracts are nothing more than self-funded bug bounties, and (2) the founders using social pressure to override the DAO contract showed that smart contracts are just as vulnerable to human interpretation as any real contract.

joefourier 5y ago
They never stopped? Smart contracts have grown vastly more sophisticated since the old DAO, with flash swaps, decentralised exchanges, overcollaterised loans, bridges, NFTs, and more ERC20 tokens than you can count.
- foxes 5y ago
  Has the added complexity had a corresponding increase in correctness?
abaga129 5y ago
Smart contracts are huge in crypto currency and are likely here to stay. Afaik all of the top 10 crypto currencies by market cap have smart contracts or plan to have them except bitcoin and tether. They power decentralized apps and defi. Without them then a blockchain doesn't have much utility aside from processing transactions.
- emerged 5y ago
  Well to be fair, blockchain doesn’t have much utility with them either.
- vimy 5y ago
  Bitcoin has smart contracts now.
  - ur-whale 5y ago
    > Bitcoin has smart contracts now. Mmmh, that's a little bit of a stretch. They're building infrastructure (eg taproot) with a goal to support them in the future. But doing ETH-like dapps on Bitcoin is nowhere near ready (or, if you listen to some Bitcoin folks, even desirable).

miohtama 5y ago

Another Solidity alternative is Vyper. It is statically typed, safe, Pythonic approach. https://vyper.readthedocs.io/en/stable/ https://vyper.readthedocs.io/en/stable/ https://twitter.com/vyperlang https://twitter.com/vyperlang Vyper is being used in Curve and Yearn (both billions of dollars of TVL): https://ethereum.org/en/developers/docs/programming-languages/python/ https://ethereum.org/en/developers/docs/programming-language...

barkingcat 5y ago
there are some significant issues about vyper that anyone using it would/should be aware of: https://blog.ethereum.org/2020/01/08/update-on-the-vyper-compiler https://blog.ethereum.org/2020/01/08/update-on-the-vyper-com... that’s not to discredit anyone using vyper, just that when putting “billions of dollars” in play on a project like this, you better have teams of folks looking into the security implications of using such a technology with known caveats that the ethereum foundation team publicised. now things may have changed in the meanwhile between the time that notice was published and now, but if you are using or recommending vyper, it’s worth it to ask or state explicitly “which” vyper and “which version” of vyper, or “did you fork vyper in order to fix some of the issues outlined in the audit” as well as “if you are using vyper in critical applications, are you contributing your fixes back to the community?” If some of the answers are "the ethereum foundation team are too conservative" "the audit doesn't mean anything" "we don't have anyone looking into the security aspects of vyper" then you have your answer: they're going to get hacked.
ur-whale 5y ago
> Another Solidity alternative is Vyper. Vitalik was pushing Vyper quite hard for a while, but he seems to have ramped that down. I wonder if Vyper is in any way better than Solidity. At any rate, smart contract languages have security / verifiability constraints that few other domain of application have, and I don't believe any of the current languages offer what is really needed (integrated formal proof of behavior of the smart contract).
- barkingcat 5y ago
  The Ethereum foundation stopped supporting the project. You can read their notice on their blog I linked.

sfjailbird 5y ago

And still not a single example of a good real world use case. I would love to be proven wrong, but all answers to this question I have seen so far devolve into a bunch of self-referential babble that leaves you no wiser at the end of it. And I'm saying this as a fan of cryptocurrencies and someone who wants to see them succeed.

number6 5y ago
A good usecase: Shares as NFT. This would make Fraud like Cum-Ex and Cum-Cum impossible. https://en.m.wikipedia.org/wiki/Dividend_stripping https://en.m.wikipedia.org/wiki/Dividend_stripping
yyyk 5y ago
>And still not a single example of a good real world use case. Ransomware, tax laundering and a relatively safe method for organized crime money transfers are excellent use cases (just not 'good' ones).
Tepix 5y ago
What do you think about Initial Litigation Offerings? Link: https://medium.com/avalancheavax/initial-litigation-offerings-to-bring-10b-asset-class-to-avalanche-blockchain-retail-investors-2aff880fa641 https://medium.com/avalancheavax/initial-litigation-offering...
- dmitriid 5y ago
  Bullcrap. Why? Any written contract can be reviewed and understood by a person. These contracts can be enforced by the use of the existing institutions. Where as something something tokens offering: - Contracts are written in an esotheric programming language that pretends to reflect a real-world contract - These contracts are unenforceable - And they still depend on some entity somewhere to enter correct info into the system. All that can be done and is being done by hundreds of companies without the use of bullshit tech.
  - sanderjd 5y ago

egberts1 5y ago

Fe? Iron-clad contract? Nice pun.

cmer 5y ago
My mind immediately went to Fee, which is quite fitting for Ethereum.

vertak 5y ago

To any Fe developers reading this: please put a non-trivial code snippet of Fe, with code comments that highlight the improvements over Solidity, front and center on the README. I am a longtime smart contract developer who has been burned by Solidity’s downsides so I am excited about new EVM languages. I’ve read the Fe README, the announcement blog post, and the Uniswap v2 examples, but still have no concrete set of improvements over Solidity that I can point to. Maybe it’s just because things are still early, but from 15 minutes looking at Fe it still seems like Solidity but this a Pythonic syntax. As a Solidity dev, I want to see concretely how Fe improves on my existing smart contract language. Thank you for pushing the frontier on smart contract development! I feel we’re in the very beginning of smart contract development and languages like Fe can be the path towards preventing tons of these hacks we see every week.

wanderingstan 5y ago
Seconding this. It’s a broader problem I find on open source repos where they bury or leave out the info a first time visitor wants: what does this thing do? Why is that better? What does it look like in practice?
davesque 5y ago
Fe founder here. I'm not currently actively working on the project and haven't been for a while. That being said, a useful bit of context is that Fe was also originally conceived as a response to Vyper. In fact, it used to be called "Rust-Vyper." Vyper was just like what you say; a python-looking smart contact language that didn't work much different from Solidity. However, it actually explicitly removed certain features in the name of security. I felt like some of what was removed was actually pretty useful and their removal might have actually decreased security (imports, multiple contracts per file, and so on). So some of what I felt Fe should do was just add those things back in. Vyper also had other issues such as (IMHO) its choice of implementation language which led to a lot of internal tech debt. Also, at the time I was working on Vyper, it actually used Python's standard parser library and so we often had to shoehorn language features into the Python syntax. Vyper may have corrected those things since then but I don't know. In any case, I eventually just decided to start over in my spare time using Rust as an implementation language. There was other work planned for Fe such as providing a "strict" compiler mode that would facilitate formal verification of contracts written in Fe (that was basically a goal of Vyper). Also, we planned to provide a thorough specification and semantics for the language also for that purpose. I believe a lot of those plans are still in place but the current team should probably comment. As you say, I think part of the issue is that things are still very early. The core devs are always figuring out useful things to add along the way that end up differentiating the language from its competitors. I'd say more but I'm on my phone :).

bob332 5y ago

Crypto is for absolute morons, stop wasting our time with such crap

mgraczyk 5y ago

For those not familiar with Solidity, there is a peculiarity in the "ABI" that makes it painful to interop between languages. In solidity, there are types called "contracts" which are like classes in other languages. When you call a function in a different contract, the dispatch is routed using the first few bytes of the has of the signature [1]. For example, to transfer ERC-20 tokens you dispatch using `hash(transfer(address, uint256))[:4]`, meaning that you put those first four bytes at the beginning of the data that you pass to the receiving contract. Just like the native world, this causes a problem when you try to interface between different languages. In Fe, the types have different names so this hashing scheme can't work without a translation layer. From some of the issues it looks like interoperability may be a problem [2]. That's ok if you write all the contracts that your dApp interacts with, but as time goes on dApps interact and call into one another more and more often. There are probably also lots of opportunities here for exploiting confusion at these boundaries, so if you're inclined and know how to use tornado you may be able to make quite a bit of money off contracts that use Fe. [1] https://docs.soliditylang.org/en/v0.8.10/abi-spec.html#function-selector https://docs.soliditylang.org/en/v0.8.10/abi-spec.html#funct... [2] https://github.com/ethereum/fe/issues/592 https://github.com/ethereum/fe/issues/592

deleted 5y ago
[deleted]
davesque 5y ago
Fe currently doesn't support the offending type and I'm pretty sure the rest of the types support the same names internally. Smart contact development isn't like native systems programming where the details of the ABI are not considered in the majority of work. I think any smart contact engineer worth their salt will immediately ask what hash will be generated by a given type and confirm that it's compatible with standard contract interfaces.
- mgraczyk 5y ago
  Yeah looking at elements.rs, it appears that they have the translation layer I alluded to: https://github.com/ethereum/fe/blob/bfeffe82b4f8623330c1ebb1950ca981449c9e86/crates/abi/src/elements.rs#L95 https://github.com/ethereum/fe/blob/bfeffe82b4f8623330c1ebb1... It's not obvious to me though and I couldn't find documentation for ABI compatibility. For example, does delegatecall to solidity work? That requires that Fe also use the same "binary" layout for storage in which slot index is used to generate the storage hash: https://docs.soliditylang.org/en/v0.8.10/internals/layout_in_storage.html https://docs.soliditylang.org/en/v0.8.10/internals/layout_in...

Fire-Dragon-DoL 5y ago

I started studying Solidity recently and found that code sharing and reuse is done through inheritance. What's the reasoning behind this? I thought we have a lot of documentation about inheritance being bad, but in Solidity not only this is core, but multiple inheritance is also core. This is then combined with (occasional) implicit access to permanently stored data, and with something that I can only describe as function inheritance. While discovering this, I started having the thought that it was done on purpose (easy to find faulty contracts that could be hacked for money). This was a nasty thought, indeed, but I found a lot of anti-features.