Parallelism

Optimizing Smart Contracts to Run in Parallel

Summary

In this section, developers can learn how to make their smart contracts run concurrently. By making these optimizations by enabling parallel execution, smart contract transactions can run concurrently, allowing Gameluk to sustain higher levels of load and throughput.

Introduction

Developers can improve the performance of their smart contracts on the chain by enabling parallel execution. To parallelize execution with Gameluk, we define the resources a contract requires access to. These resources are then used to create a parallelization plan for a block. Transactions with mutually exclusive resource requirements can execute in parallel, while those with shared resources are appropriately ordered to preserve in-order access to the shared resource.

To encourage developers to parallelize their smart contracts, a 50% gas discount is automatically applied to contracts that have clearly defined their resource requirements and dependencies.

To parallelize the execution of a wasm contract, the developer must review the execute messages implemented by the contract and identify any other chain resources (executes or queries) required for execution. Contract developers must include resources used by any execute messages that the contract may return for further execution, including queries for chain native information such as oracle prices or bank balances, as well as queries to other wasm contracts. It is important to adhere strictly to metrics and units, use precise word choice, and maintain a formal tone. Contract developers must include resources used by any execute messages that the contract may return for further execution, including queries for chain native information such as oracle prices or bank balances, as well as queries to other wasm contracts. Additionally, the language should be direct and unambiguous to avoid confusion. The developer must also take into account any chain native messages, such as bank sends, that may be returned by the contract. The text should be free from grammatical errors, spelling mistakes, and punctuation errors.

After identifying these resources, the contract developer must register them with the chain so that they can be referenced when parallelizing transactions in a block. This is achieved by submitting a JSON-formatted proposal that specifies all the resources the contract may require access to. Below is an example of such a proposal that can be used as a template for developers to register their own contract dependencies.

{
    "wasm_dependency_mapping":
        {
          "contract_address": "{your-contract-address}",
          "base_access_ops": [
            // you can replace these with your own dependencies
            {
              "operation": {
                "access_type": "UNKNOWN",
                "resource_type": "ANY",
                "identifier_template": "*"
              },
              "selector_type": "NONE"
            },
            {
              "operation": {
                "access_type": "COMMIT",
                "resource_type": "ANY",
                "identifier_template": "*"
              },
              "selector_type": "NONE"
            }
          ]
        }
}

When defining the dependencies as part of the proposal, you can base them off of the parallelization guide for different module messages and queries, and can customize them appropriately by using Selectors.

Once this json file is built, the developer can register it with the chain with the tx below:

gameid tx accesscontrol register-wasm-dependency-mapping $JSON_FILEPATH --from