Security specific features in Sway

Sway
1

Hi,

I became interested in Sway smart contract programming language, as it is touted to be a more secure alternative to Solidity and Rust. However, after eyeing through Sway documentation, I did not find anything security specifics. What are the security-specific parts of Sway that are more innovative than other smart contract programming languages?

8 Likes
2

Just off the top of my head:

  • Type safety everywhere. E.g. for Identities (contracts vs EOA addresses)
  • A rich, maintained standard library which does things once and does them right
  • Compile-time reentrancy checks
  • Explicit storage access annotation for functions
  • Namespaced storage variables (storage.myvar)
  • Zero-cost abstractions, meaning no need for obscure gas-golfing techniques that sacrifice readability and security for performance.
  • And many more :slight_smile:

The Fuel book gives a higher level overview of the design choices in the VM and the language, including some comments on safety and differences with Solidity.

7 Likes
3

Thank you so much Simon.

It is nice to see good progress on smart contract security. To continue on this topic of Fuel (not Sway), I assume any asset (or token) does not suffer the widely spread approve() and message signing issues Ethereum is enjoying? This is a part of security that sits between the chair and the keyboard and it seems poor wallet smart contract UX is a good way to have your apes running back to the forest.

Will the user interaction with smart contracts be safer? Any tricks Fuel does to accomplish this?

1 Like
4

Since the UTXO model allows all tokens on Fuel to be native assets, the approve/transferFrom mechanism is unnecessary; any token can be forwarded with a call. The #[payable] annotation also help avoid any errors here.

2 Likes