Best Practices

Smart Contract Design Patterns

Design patterns are architecture design and programming best practices. Understanding patterns not only help the user understand how to deal with a problem but also why it needs to do it in a given way and what problem the pattern is designed to deal with.

Behavioral Patterns

Guard Check: Ensure that the behaviour of a smart contract and its input parameters are as expected. State Machine: Enable a contract to go through different states with different corresponding functionality exposed. Oracle: Gain access to data stored outside of the blockchain. Randomness: Generate a random number of a predefined interval in the deterministic environment of a blockchain.

Security Patterns

Access Restriction: Restrict the access to contract functionality according to suitable criteria. Checks Effects Interactions: Reduce the attack surface for malicious contracts trying to hijack control flow after an external call. Pullover Push: Shift the risk associated with transferring XLG to the user. Circuit Breaker: Add an option to disable critical contract functionality in case of an emergency. Speed Bumps: introduces a delay in the action execution allowing time to act if action is considered malicious. Arithmetic: Integer overflows and underflows are dangerous in smart contracts. If these occur, many benign-seeming code paths become vectors for theft or denial of service.

Upgradeability Patterns

Proxy Delegate: Introduce the possibility to upgrade smart contracts without breaking any dependencies. Eternal Storage: Keep contract storage after a smart contract upgrade.

Economic Patterns

String Equality Comparison: Check for the equality of two provided strings in a way that minimizes average gas consumption for a large number of different inputs. Tight Variable Packing: Optimize gas consumption when storing or loading statically-sized variables. Memory Array Building: Aggregate and retrieve data from contract storage in a gas efficient way.

Frameworks & Libraries

OpenZeppelin is a library for secure smart contract development. It provides implementations of standards like ERC20 and ERC721. The following are the most common recommendations of the framework.

math/SafeMath.sol: Protect from overflow and underflow. Never use default arithmetic operators. Arithmetic operators do not fail when there is overflow or underflow, which may be exploitable.

ownership/Ownable : Save the contract creator address as the owner, and check if a calling address is the owner or not with modifier onlyOwner. The ownership can be transferred to other addresses. This is an application of the Access Restriction Pattern.

lifecycle/Pausable: Provides an emergency stop mechanism. Stops the contract from running in emergency situations to reduce damages. This is an application of the Emergency Stop Pattern.

access/rbac/RBAC: Role-based access control. An application of the Access Restriction Pattern. RBAC is a more flexible way to manage access controls than Ownable. It can have multiple admins, whereas Ownable only allows a single owner to have control over the contract.

token/ERC20 : The smart contracts provide a set of contracts implementing common ERC20 token features. We can easily build an ERC20 token with these base contracts by using multi-inheritance.

Block Producer Considerations

Monitoring

Monitoring a network for security events start from log collection activity. The Ledgerium Blockchain network as any other network should produce logs, that must be analyzed for anomalies. The following parameters are of interest to be collected and analyzed:

  • Hosts access and events

  • Ethereum accounts on the network

  • Active ledger, transaction manager nodes in the network

  • Public and Private transaction rates per account in the network.

  • The number of public Smart contracts in the network.

  • Network connections to block producers and metadata.

  • Consensus protocol metadata (E.g Block creation rate, and source ...etc)

Block Producer Security Checklist

Centralised log system: Ensure all activities of Ledgerium Block Producer are being logged to the centralised log system and are able to provide query capabilities over the following parameters:

  • The Ledgerium accounts on the network

    • Active ledger, transaction manager nodes in the network

    • Public and Private transaction rates per account in the network.

    • The number of public Smart contracts in the network.

    • Network connections to ledger nodes and metadata.

    • Consensus protocol metadata (E.g Block creation rate, and source ...etc)

  • Logs must be backed-up and integrity verified.

  • An alerting system should be put in place in order to monitor consensus protocol anomalies