[Discussion] Smart Contract Container

Development
1

One of the critical issue developers have that is blocking them to launch is security of their smart contracts.

It spans from seeing many hacks across the industry, where millions are stolen every week. Smart contracts can be programming simple logic and be moving millions of dollars, and developers have less control than usual around the transition from dealing with $1k and with $1m when it’s out in the open on MainNet.

This discussion is to propose an idea of a “Container” that will really make it as secure as possible for smart contract.

The possible controls for the sandbox:

  • Limit amount of money held in the contract
  • Limit amount of money transferred in and out of the contract per day
  • Pause functionality
  • Upgrade functionality
  • Limiting with whitelist of who can access the smart contract (with NEAR accounts it can be even *.blah.near for example). Can be doing invitations or backend server to authorize based on some other account like Google.

What are other limiting factors we should do? What are other ways we can make contracts more secure earlier and make developers feel safer to launch (and users of cause to be the first to test it) on MainNet?

(Not discussing yet implantation, but I see two options: WASM in WASM or customized SDK)

8 Likes
2

This could be important for attracting enterprise developers.

Would all contracts be executed in the sandbox or would this be something new contracts could optionally use after it’s been implemented?

The possible controls listed could be implemented via libraries, similar to OpenZeppelin. In Rust these could be macros: #[limit_balance(500_000_000)], #[pauseable], etc. Though I could be missing something?

Crazy idea - the sandbox as an observation environment

This might not be possible, but I’ll put it out there in case it sparks a thought in someone else.

The sandbox could be used to allow for reversals of txs without breaking consensus by functioning like a mini sidechain. Txs processed in the sandbox are delayed N blocks, with a rollup periodically committed to the main chain. A sentry could observe the sandbox txs and choose to respond to malicious ones before they propagate to the main chain.

For example: some transactions attempt to drain a contract balance, near-sentry picks it up, reverts that tx and subsequent ones in the sandbox to preserve consensus. Those txs resolve to something like Error: Security exception triggered., refunding the innocent txs and consuming the NEAR of the attacker. Then the box fills up again as normal.

There are many unknowns here, such as: the economics for validators, and how to handle a cross-contract call between a standard and sandbox contract. These contracts would likely have limited functionality, but could be good for things like vaults.

Other ways to make contracts more secure

  • Fuzzing Tool
  • SWC (Smart Contract Weakness Classification)
    • Registry of smart contract weaknesses with recommendations for overcoming them
    • Fix recommendations especially make this very helpful.
    • It might be a little early for this, as many common, optimal patterns are likely not yet established.
  • Code Coverage Tool
    • User requested!
    • Could potentially get away with a guide for Rust and AS based on existing tooling for those ecosystems
    • Coveralls is one example
3 Likes
3

Just want to comment that I found this post because I was searching for “Sandbox” which is the term for the nearcore feature flag that is being used to replace simulation tests. So if we roll this out, would like to suggest we join heads on naming.

1 Like
4

@mikedotexe raises a good point. I suggest smart contract container, since sandbox implies it can get thrown away.

1 Like