Review of smart contract

Smart Contracts
1

Dear support, we are currently preparing go-live on Mainnet with our Smart Contract.

Is it possible to get help with review of the Smart Contract code, to make it future proof (changes, adjustments) and also to make it more efficient if needed. Short of a peer-review.

Also is there anything we should consider when having a node connected to Mainnet - security, configuration, etc.

Thanks

2

Hello NHS

I will speak with one of our experts to arrange something with you.

Regards,
Concordium Tech Support

1 Like
3

One last question: Did you run your smart contract trough our Testnet? Any experience from there taht you would like to discuss?

4

Yes, we have been testing the contract for 3-4 months on testnet - in combination with our backend services

5

It runs fine in our view - but always good to get input - so we would like review

6

I spoke with the team, but unfortunately, due to our resources, we do that kind of service only for those companies in our grant program.

7

Hi @NHS,

As Zoltan said, we don’t perform reviews of smart contracts for companies outside our grant programme. However, if you have more concrete concerns about specific sections in your smart contract, then we can certainly take a look. If you choose to do so, then please also include some context about what the expected behaviour is and how it fits into the bigger picture of the smart contract or system.

As for the security of a node on mainnet, there are a few things to be aware of regarding the gRPC interfaces.
The node currently supports two gRPC interfaces, the old, v1, and the new, v2.
The old interface is still used by several of our tools, including the NodeJS SDK and Concordium Client, but we are working on migrating them to v2.

The primary concern here is that the node can be shut down via either of the gRPC interfaces and the node can also be DDOS’ed if either of the gRPC interfaces is made public.

By default, the node only runs the gRPC v1 interface. gRPCv2 can be enabled with the --grpc2-* named arguments to the node binary (or CONCORDIUM_NODE_GRPC2_* environment variables). You can run concordium-node --help for more info.

Protecting the gRPC v1 interface
Here are some different options, some of which can be combined:

  1. Disable the interface with --no-rpc-server if you don’t need it. (The Rust SDK can use the v2 interface)
  2. Don’t make the interface publicly accessible (you could also protect it behind a VPN)
  3. Limit the number of requests via a proxy or similar. (Protects against DDOS but not the node shutdown).

We recently added a feature that allows you just to disable the node management endpoints in gRPC v1 (including the shutdown). We have not made a release with this feature yet, but it will be included in the next release. If you urgently need it, you can build the node yourself, or we can build it for you.

Protecting the gRPC v2 interface
Here are some different options, some of which can be combined:

  1. Don’t enable the v2 interface (the default behaviour of the node).
  2. Don’t make the interface publicly accessible (you could also protect it behind a VPN)
  3. Limit the number of requests via a proxy or similar. (Protects against DDOS but not the node shutdown).
  4. The specific endpoints available in v2 can be configured easily, as described in this document.

I hope this clarifies what steps you may take towards a more secure setup. Feel free to ask more questions or, as I said, ask specific questions regarding your smart contract.

Have a pleasant day.

Best regards,
/ Kasper

1 Like
8

Hi,

okay. Thanks, we will get back if needed.

9

To clarify, “next” release here does not mean the very next one (5.1.). It will be in the subsequent release (likely version 5.2.) sometime in February most likely.

2 Likes
10

Hi Support,

we have reviewd our Smart Contract and used patterns and have some clarifications we hope you can help with:

  • On smart-contract code changes/upgrades, which pattern has so far been tested, or which is best or applies for Concordium? The patterns we’re referring to are #2-#5 of this pattern page: Upgrading smart contracts | ethereum.org. Can you please share a link of the public code that implements one of these patterns for the Concordium smart contract? Or is it best to use the Concordium upgrade approach described here:

Make a contract upgradeable — Concordium documentation?

  • We have not really explored or used “events” yet. We can’t see any detailed examples of how to use it and for what. How is it any different from just changing the state since both changing the state and adding events have a cost? If we log an event, can we have a component somewhere extracting or listening for these events so that the calling component of the smart contract does not have to wait for something to be finalized before it returns? Where and how can we listen to these events?
11

Regarding upgrades, we strongly recommend using the native built-in upgradability unless that is too limited.

Events are meant for off-chain applications to monitor the contract without having to understand its state.

For example, our CIS2 token standard mandates that CIS2 contracts must emit certain events for transfers of tokens, and minting of tokens. This makes it possible for off-chain tools to keep track of all balance changes in the contracts by just looking at transaction outcomes on the chain.

We make use of this in our transaction-logger for example concordium-transaction-logger/src/main.rs at main · Concordium/concordium-transaction-logger · GitHub

You can look at the logger linked above to see how to process these events. But essentially you would use the get_block_events endpoint and look at transactions, and extract the transaction events you care about.

I do not think this is a good idea. You should wait for finalization regardless of whether you look at events or not. Until the transaction is finalized it is possible that its outcome (including ghe events it has generated) change.

12

Thank you! we will review it and get back if needed

13

Hi, in addition to this. Do you know of any companies or individuals that know Smart Contracts on Concordium at an expert level that could be hired to help with a review and assessment of Rust code used for smart contracts? It is just to be sure that we follow best practices, and have not missed anything etc.

14

Hi, sorry for not getting back to you.

We are not aware of any companies that offer expert reviews of Concordium smart contracts, but there are several companies that offer similar services for other types of smart contracts. Perhaps you can reach out to some of them?
We also have a best practices section in our documentation, which will likely help you in making a solid contract.

Best regards,
Kasper

15

Hi Kasper, thanks for getting back. We found someone that could help.

1 Like