Introduction​

In the development of the xSigners multisig project, tailored for Substrate blockchains containing contracts pallet, our primary objective was to uphold the principles of decentralization while simultaneously striving to minimize operational costs. This document aims to elucidate the various decisions and trade-offs encountered during the project's lifecycle, particularly focusing on aspects such as user experience, on-chain expenses, and contract storage management.

The xSigners multisig solution was conceptualized to enhance security and collaborative decision-making in the management of digital assets and contract interactions on Substrate-based blockchains. By leveraging the ink! smart contract platform, we were able to create a robust and flexible multisig contract. However, this journey was not without its challenges. We had to carefully balance the inherent limitations of blockchain technology, such as storage costs and computational overhead, against the need for a seamless and user-friendly experience.

Integration of Subsquid in the xSigners Multisig Project​

In addressing the challenges of user experience and on-chain data management in the xSigners multisig project, we turned to Subsquid, an innovative indexing and storage engine for blockchain data. Subsquid's integration plays a crucial role in streamlining the flow of information within our application. By harnessing its ability to aggregate and archive on-chain data, we have significantly enhanced the way users interact with our multisig solution. This integration allows for a more consolidated and efficient presentation of data, crucial for decision-making in a multisig environment.

One of the key benefits brought by Subsquid is its GraphQL API, which facilitates easy and flexible queries. This feature enables the application to efficiently extract and present vital information such as events, balances, and other contract-related metadata. The result is a substantial reduction in the user experience (UX) friction that was previously a challenge. Users are no longer burdened with the manual task of sharing individual contract addresses and details. Instead, the Subsquid processor efficiently collates this information and provides it through a unified gateway, simplifying user interactions with the multisig contract.

Understanding Subsquid: An Overview​

Subsquid serves as a powerful indexing and storage engine for blockchain data, a critical component in modern blockchain applications. Its primary function is to efficiently process, aggregate, and archive data from blockchain networks. This capability is essential for applications that require quick and easy access to a big array of on-chain information. Subsquid achieves this through its advanced data processing capabilities, which transform raw blockchain data into a more accessible and usable format.

The core advantage of using Subsquid in blockchain projects, such as the xSigners multisig, lies in its ability to provide a more streamlined and user-friendly data interaction experience. With its GraphQL API, Subsquid allows for sophisticated and customizable data queries. This means that applications can offer their users a more intuitive and responsive interface, with the ability to access a wide range of data points without the complexities and limitations of direct on-chain data retrieval. This approach not only enhances the user experience but also contributes to the overall efficiency and effectiveness of the application.

Building upon the integration of Subsquid in the xSigners multisig project, a significant advantage emerges in the form of accessing historical data. With Subsquid's indexing capabilities, users can effortlessly view older transactions without the need to delve into dated blockchain snapshots. This feature is particularly beneficial in a multisig context, where tracking the history of transactions and contract interactions is crucial for transparency and auditability. By providing a streamlined method to access this historical data, Subsquid enhances the user experience, making it simpler and more efficient to review past activities and decisions made within the multisig contract.

Despite the convenience and efficiency offered by Subsquid, it is crucial to emphasize that decentralized data integrity remains at the forefront of our priorities. The core functionality of the underlying contract palette and its state transitions continue to operate in a backendless, decentralized paradigm. This means that while Subsquid acts as an efficient access layer, providing a user-friendly interface for data retrieval and interaction, it does not have the capability to alter any on-chain settlements. The immutable nature of blockchain ensures that all contract interactions and settlements remain tamper-proof and transparent, upholding the trust and security inherent in decentralized systems.

All core logic on-chain​

The architectural decision to keep all core logic on-chain in the xSigners multisig project opens up a realm of possibilities for community engagement and innovation. By maintaining the contract logic on the blockchain, we ensure that the system is not only transparent and secure but also accessible for external developers. This approach allows anyone in the community to create their own frontends or interfaces to interact with the contracts. Such openness fosters a collaborative ecosystem where developers can contribute to the project's growth, experiment with new user interfaces, or even build specialized tools tailored to specific needs, all while interacting with the same underlying, reliable smart contract logic.

Facing some event handling issues​

Before delving into the proposed enhancements for the next version of the xSigners multisig project, it is important to address a key challenge encountered in the current implementation: the ambiguity of certain emitted events from the blockchain. While blockchain events are crucial for tracking and responding to contract interactions, they sometimes lack the clarity and specificity needed for effective application logic. This issue is particularly evident in the context of our project's reliance on Openbrush for handling PSP Token events. Notably, Openbrush does not emit events, as highlighted in their documentation. This limitation necessitates additional post-processing of on-chain data to accurately interpret and utilize these events within our application.

To address this, the next version of the xSigners multisig project will incorporate a more robust mechanism for post-processing blockchain events. This enhancement aims to extract clearer and more actionable insights from on-chain activities, ensuring that the application can respond accurately and efficiently to contract states and changes. By refining our approach to handling and interpreting blockchain events, we can overcome the limitations posed by the current ambiguity and lack of event emissions in some contract interactions. This improvement is not only crucial for maintaining the integrity and functionality of the multisig system but also sets the stage for the more advanced backend integration features proposed in the following notes.

Notes for Next Version: Backend Integration for Signature Management​

• Backend-Driven Signature Collection: Implement a backend system that allows users to send their signatures to a centralized service. This approach would streamline the process of gathering signatures for multisig transactions, especially in scenarios where multiple confirmations are required.

• Threshold-Based Transaction Execution: The backend would monitor the number of affirmative signatures collected. Once the predefined threshold is reached, indicating sufficient consensus among the parties involved, the backend would then automatically prepare for the next step of executing the transaction.

• Bulk Transaction Posting: Instead of posting each signature to the blockchain individually, the backend could aggregate all the required signatures and post them in bulk. This would result in a single transaction being sent to the blockchain, representing the collective approval of the multisig participants.

• Cost and Efficiency Optimization: By consolidating multiple signatures into a single transaction, this method would significantly reduce the number of transactions required on the blockchain. This not only optimizes the cost associated with transaction fees but also enhances the efficiency of the process.

• Security Considerations: While this approach adds convenience, it's crucial to assess and implement robust security measures within the backend to safeguard the signature collection and transaction execution process.

• User Experience Improvement: This backend integration aims to simplify the user experience, making the process of multisig approvals more seamless and less time-consuming for the users.

Conclusion​

In conclusion, the journey of developing the xSigners multisig project for Substrate blockchains has been both challenging and enlightening. We navigated through the complexities of maintaining decentralization, optimizing costs, and enhancing user experience, all while adhering to the stringent requirements of newest technology. The integration of Subsquid addressed significant challenges related to data accessibility and user interface, demonstrating the power of combining on-chain logic with off-chain data processing. Furthermore, our commitment to keeping all core logic on-chain has opened avenues for community-driven innovation, allowing others to build diverse and customized frontends.

As we look towards the future, the proposed enhancements in signature management and event processing signify our ongoing commitment to evolving and improving the xSigners multisig project. By considering the integration of a backend system for more efficient signature collection and transaction execution, along with refining our approach to blockchain event interpretation, we aim to further streamline the multisig process. These advancements will not only enhance the user experience but also maintain the integrity and security that are paramount in blockchain applications.

The xSigners multisig project stands as a testament to the potential of collaborative development in the blockchain space. It showcases how innovative solutions can emerge from the challenges of working within a decentralized framework, and how these solutions can lead to more efficient, user-friendly, and secure blockchain applications. As we continue to develop and refine our MVP, we remain dedicated to pushing the boundaries of what is possible in the realm of blockchain technology, always with an eye towards the needs and experiences of our users. Our journey thus far has been a blend of technical innovation and practical problem-solving, and we are excited about the future possibilities this project holds. The lessons learned and the successes achieved serve as a foundation for not only our team but also for the broader blockchain community, inspiring further exploration and development in this dynamic field.

By continuously adapting and improving, we aim to contribute to a more secure, efficient, and user-centric blockchain ecosystem. We look forward to the continued support and collaboration from the community as we embark on the next phase of this exciting journey.

Resume​

This document outlines the architecture of a contract pallet multisig implementation without a backend. It provides a detailed view of the system’s structure, components, and interactions, focusing on the advantages and disadvantages of a backendless approach.

System Architecture​

The system architecture is primarily composed of the on-chain component.

On-Chain Component​

The on-chain component consists of the contract pallet and the multisig contract. The contract pallet is a module in the Substrate framework that allows us to write and deploy smart contracts on a blockchain. The multisig contract is a type of smart contract that requires multiple parties to sign off on transactions.

In a backendless architecture, the on-chain contract is more complex. It needs to store all proposed transactions and have a logic for removing them. This increases the complexity and size of the on-chain contract.

Here’s an overview of its main data structures and functions:

Data Structures​

Transaction — Represents a transaction that can be performed when a threshold is met. It includes the receiver’s address, the function selector, the input data, the value to be transferred, the gas limit, and a flag that indicates whether re entry is allowed.

MultiSig — The main data structure of the contract. It includes the list of owners, the threshold needed to approve transactions, a list of transactions, and a list of approvals and rejections. It also includes a mapping of transactions and approvals for constant-time access.

Constructors​

new — Creates a new multi-signature wallet with a specified threshold and a list of owners.

default — Creates a default multi-signature wallet with the caller as the single owner and a threshold of 1.

Functions​

propose_tx — Proposes a new transaction. Only an owner can propose a transaction. It checks the maximum number of transactions hasn’t been reached, stores the transaction, and if the threshold is met (in cases where the threshold is 1), it executes the transaction.

approve_tx — Approves a transaction by an owner. If the threshold is met with this approval, the transaction is executed and then removed.

reject_tx — Rejects a transaction by an owner. If the threshold can’t be met with the remaining approvals, the transaction is deleted.

try_execute_tx — Execute a transaction if the threshold has been met and remove it from the storage. It’s called try because nothing is done if the condition is not met. The external invocation of this function is permitted, although it is designed to be invoked automatically by the approve_tx. We have identified specific exceptional scenarios where manual invocation of this function is necessary.

try_remove_tx — Remove a transaction if the threshold cannot be met with the remaining approvals. It’s called try because the condition is checked too. As mentioned in the description of try_execute_tx, this function is executed automatically. However, there are certain exceptional situations where manual invocation of this function becomes necessary.

add_owner — Adds an owner to the contract. The maximum number of owners is limited. It’s a self call function that can be called by the same contract passing the approval process.

remove_owner — Removes an owner from the contract. This is a self call function too change_threshold — Changes the threshold necessary for transactions to be approved. This is a self call function called only if approval process has been finalized

transfer — Transfers funds to a specified address. This is also a self call function.

In addition to these, there are a number of getter functions to read the state of the contract such as getting the list of owners, the threshold, transactions, approvals, and rejections that will be used by the front end application.

The contract uses events for logging operations like transaction proposal, approval, rejection, addition and removal of owners, threshold change, and transfer of funds. This makes the contract traceable from an event subscriber.

Off-Chain Component​

The off-chain component is a web application, primarily built using a technology stack that includes React, NextJS, and TypeScript.

React, a popular JavaScript library for building user interfaces, along with NextJS, a React framework for production-grade applications, are used to construct the frontend application. This application communicates with the on-chain component, submits transactions, and displays information to the user.

TypeScript, a statically typed superset of JavaScript, is used to ensure type safety and improve the development experience. It helps catch errors early in the development process and enhances code readability and maintainability.

Please note that this is the proposed technology stack and it may be supplemented with other libraries or tools as necessary to meet specific requirements or to enhance the functionality and performance of the off-chain component.

Advantages and Disadvantages​

Advantages​

Decentralization: A backendless approach maintains the decentralized nature of blockchain technology. There’s no need to trust a separate entity managing a backend.

Reduced Operational Costs: Without a backend, you save on the costs associated with maintaining and operating a backend service.

Disadvantages​

User Experience: Without a backend to centralize information, the user interface and experience may be less streamlined. Users may need to share the metadata of the deployed contract. Increased On-Chain Costs: Without off-chain signing, the computational and financial costs associated with on-chain transactions may be higher. All transactions, successful or not, interact with the contract. Limitations: Without a backend, you may face the limitations of the smart contract pallet, such as a maximum storage of 16k on each contract.

State transition cases​

This scenario illustrates a contract that involves three owners and a threshold of two. Alice, one of the owners, suggests adding Dave as a new owner. Bob, another owner, gives his approval. Once the threshold is met with Bob’s approval, Dave is successfully added as a new owner

In the following scenario, the contract is the same as the previous example. Alice suggests adding Dave as an owner. However, both Bob and Charlie reject this proposal. As a result, Dave is not added and the transaction is subsequently removed.

Trust and Metadata​

Regardless of whether a backend is used, there’s an inherent trust issue around metadata sharing. The metadata of third-party contracts can’t be easily verified, making this a significant and risky aspect of contract pallets multisig implementation.

Conclusion​

This architecture document provides a high-level view of a contract pallets multisig implementation without a backend. It highlights the key components and their interactions, as well as the advantages and disadvantages of a backendless approach. As with any architectural decision, it’s crucial to weigh these factors against the specific needs and constraints of your project.

A Journey with Protofire​

Introduction​

This research article provides an exploration of the Contract Pallet. The motivation behind this comprehensive study stems from our proposal to develop a multi-signature wallet using the Ink! smart contract language.

The proposal identifies a significant gap in the Dotsama ecosystem: the absence of a smart contract multi-signature wallet that allows users interacting with smart contracts securely.

The team at Protofire DAO aims to address this gap by implementing an Ink! smart contract with a user interface focused on the user experience. However, to successfully develop this solution, a deep understanding of the underlying technology — the Contract Pallet — is necessary. This is where the research article comes into play.

The article delves into the intricacies of parachains and smart contracts, the role of the Contract Pallet, the limitations of smart contracts, the use of Ink! as a language to write this contract, and much more. It provides the foundational knowledge required to comprehend the complexities of developing a multi-signature wallet in this ecosystem.

By understanding the detailed workings of the Contract Pallet, developers can better appreciate the challenges and opportunities presented by the proposal.

Parachains and Smart Contracts: A Comparative Analysis​

Parachains​

When it comes to Substrate, Polkadot, or Kusama, a common question is when to develop a parachain versus when to develop a smart contract.

In the context of Dotsama, a parachain leases a slot for a specific period, typically up to two years. The lease grants the parachain a fixed slot to execute its business logic, also known as its state transition function, and store its modified state in a block. In Substrate terminology, this state transition function is referred to as the chain’s runtime.

It’s crucial to understand that a parachain’s state transition function is not further validated; it’s up to the parachain to decide how it utilizes its slot time. The parachain has already prepaid for its slot through the slot auction. This prepayment grants the parachain the freedom to construct its own blockchain world. For instance, it can decide how transaction fees are charged or even opt not to charge any transaction fees at all. These options are significant when creating new and user-friendly business models. However, the parachain must adhere to certain ground rules. One such rule is the consensus algorithm that governs communication between the Relay Chain and the parachain. These ground rules contribute to the advantages of Polkadot and Kusama, such as shared security, cross-chain communication, and guaranteed execution slot time.

Smart Contracts​

​Polkadot distinguishes itself from other ecosystems by having parachains and smart contracts exist at different layers of the stack, with smart contracts residing on top of parachains.

An existing parachain needs to include the Contract Pallet module to allow users to deploy smart contracts. These contracts are always considered untrusted code. Anyone with tokens of the chain can upload one without requiring permission. Smart contracts enable the permissionless deployment of untrusted programs on a blockchain. The Contract module assumes that these programs may act adversarially, so it incorporates various safety measures to prevent the contract from stalling the chain or corrupting the state of other contracts. Some of these safety measures in this pallet include gas metering and deposits for storing data on-chain.

Summary​

To summarize this crucial distinction: developing a parachain runtime is different from developing a smart contract, as a smart contract sits on top of a parachain.

The decision between constructing a parachain and developing a smart contract presents a unique set of trade-offs. When you opt for a parachain, you gain the freedom to establish all thegoverning rules of the chain. This freedom, however, comes with the responsibility of managing governance and crypto-economics, among other factors.

On the other hand, the development of a smart contract is a more streamlined process. Developers only require a few tokens to deploy a smart contract. However, this simplicity comes with its own set of constraints. Smart contracts are bound by the rules set by the chain and must adhere to necessary safety measures. Additionally, due to the extra logic involved, a smart contract can never match the speed of a native pallet built directly into the parachain runtime.

The Role of Contract Pallet​

Main Functionality​

The Contract Pallet is responsible for deploying and executing WebAssembly smart contracts within the runtime.

These smart contract accounts have the capability to create instances of smart contracts and make calls to both contract and non-contract accounts.

Smart contract code is stored once in a code cache and can be retrieved using its hash. This means that multiple instances of smart contracts can be created from the same hash without duplicating the code.

When a smart contract is called, its associated code is retrieved using the code hash and executed. This call can modify the storage entries of the smart contract account, create new smart contracts, or invoke other smart contracts.

Regarding the calls done to a smart contract, senders must specify a gas limit for each call, as all instructions invoked by the smart contract require gas. Unused gas is refunded after the call, regardless of the execution outcome.

Error Handling​

Failures in sub-calls do not propagate to the calling contract. When a failure occurs in a sub-call, it does not affect the entire call stack, and the call will only revert at the specific contract level. For instance, if the gas limit is reached, all calls and state changes (including balance transfers) are reverted only at the current contract level.If contract A calls contract B and B runs out of gas during the call, all of B’s calls are reverted. A can decide how to handle the failure, either by continuing execution or reverting A’s changes.

The Challenge​

When the multisig contract makes a call to another contract and that call fails, it needs to decide how to handle the failure. This decision-making process needs to be designed with care. It’s important to ensure that the multisig contract behaves correctly and predictably in the face of sub-call failures. This might involve implementing robust error handling mechanisms and providing clear feedback to the contract owners about the outcome of calls.

Furthermore, the gas limit for sub-calls needs to be set judiciously to minimize the risk of running out of gas.

Limitations​

It’s important to note that the scope of smart contracts is primarily limited to the Contract Pallet itself, and they generally cannot directly access other pallets within the Substrate framework.

In the Contract Pallet’s default configuration, smart contracts can interact with the runtime through a set of predefined basic smart contract interfaces. This API offers various interactions, including the ability to call and create other smart contracts on the same chain, generate events, access contextual information, and perform cryptographic operations. However, if the default feature set does not meet the requirements of a particular Substrate-based blockchain, the chain extension feature can be used to expand the API and provide access to additional runtime logic.

ink!: An Embedded Domain-Specific Language​

ink! is an embedded domain-specific language designed for the Rust programming language. It enables developers to write smart contracts using the familiar Rust syntax, augmented with additional features tailored for this domain. The Contract module within Substrate is responsible for executing these contracts in a secure manner. In essence, ink! allows you to leverage Rust to write smart contracts for Substrate-based blockchains that incorporate the Contract Pallet module.

In this document, our focus will be solely on providing the relevant information necessary to achieve our goal of building the multisig functionality. Therefore, we will skip the general information about the ink! programming language and instead, we will present the specific and relevant information gathered from our research that is crucial for achieving our desired objective.

Storage​

In ink!, storage data is always encoded using the SCALE codec. The storage API functions by storing and retrieving entries in/from individual storage cells, each with its own dedicated storage key. This approach is similar to a traditional key-value database.

There are two types of storage layouts: Packed and Non-Packed. Packed types can be stored entirely in a single storage cell. By default, ink! attempts to store all fields of a storage struct in a single cell. With a Packed layout, any contract message interacting with storage will need to operate on the entire storage struct. For small storage structs with a few fields, retrieving all data from storage in every message is not an issue and may even be advantageous. However, if a contract stores a large vector or structure but provides messages that don’t require accessing it, there will be unnecessary runtime overhead and extra gas costs.

If a Packed layout type becomes too large (such as an ever-growing Vec), it can break the contract because encoding and decoding storage items have a limited buffer capacity (around 16KB in the default configuration). Contracts trying to decode beyond this capacity will encounter an error. To handle potentially large data structures, consider using an ink! Mapping, which can store an arbitrary number of elements.

The Challenge​

In the context of the multisig contract, the storage layout design is a critical aspect that needs careful consideration. It determines how data is stored and retrieved, which directly impacts the contract’s performance and gas costs. We may need to accommodate potentially large datastructures, such as the list of owners and the list of active transactions. If these lists grow too large, they could exceed the buffer capacity for encoding and decoding storage items.

To avoid this, it’s important to define a maximum number of owners and active transactions that can be stored on-chain. These limits need to be chosen carefully to ensure that they are large enough to provide the necessary functionality, but not so large that they risk breaking the contract.

Selector​

Selectors in ink! are a way to identify constructors and messages in a language-agnostic manner. These selectors are four-byte hexadecimal strings, such as “0xad6d4358”.

In ink!, a unique selector is automatically generated for each message and constructor by default. This is a crucial step because when the contract is compiled into a WebAssembly (Wasm) blob, the original method names are no longer retained. Instead, these selectors serve as identifiers for the corresponding methods. When a function needs to be invoked, it’s the selector that is called upon, effectively mapping to the intended method within the contract’s underlying layers.

To find the selector of a constructor or message in an ink! contract, you can refer to the “selector” field in the contract’s metadata for the specific dispatchable you are interested in.

If the contract’s metadata is not accessible, you can calculate the selector yourself using a straightforward algorithm

1. Take the name of the constructor or message.
2. Compute the BLAKE2 hash of the name.
3. Extract the first four bytes of the hash as the selector.

Ink! also allows using custom selectors, and while they offer the advantage of allowing function name changes while preserving the selector, they also pose certain risks. Unlike Solidity, ink! does not require matching function signatures with selectors, making it easier for scammers to exploit this vulnerability. Furthermore, custom selectors can cause confusion for third-party monitoring and indexing services that rely on standard selectors, potentially leading to errors in transaction monitoring.

Auto-generated selector example:​

#[ink(message)]
pub fn add_owner(&mut self, owner: AccountId) -> Result<(), Error> {
  ...
}

1. add_owner
2. blake_2(“add_owner”) 0xad6d4358e5e509481528506e3b61c84ed6c56230ec3a2a1a0f48359c6641af30
3. fn selector: 0xad6d4358

Custom Selector Example:​

#[ink(message, selector = 0xAAAAAAAA)]
pub fn add_owner(&mut self, owner: AccountId) -> Result<(), Error> {
  ...
}

Considering that the selector is set in an arbitrary manner,, its value is not computed based on the function name.

• fn selector: 0xaaaaaaaa

The Challenge​

Unlike typical contracts that interact with a predefined set of other contracts, the multisig contract is designed to interact with any on-chain contract. This necessitates a more low-level approach, where instead of calling a function by name, the function is invoked using its method selector.

When a transaction is proposed to the multisig contract, the method selector must be provided along with other required parameters. However, obtaining this selector is not straightforward. It is part of the contract’s metadata, which needs to be obtained and trusted.

The challenge lies in securely obtaining and verifying this metadata. It could be provided by one of the owners or retrieved from a trusted server, but either way, it needs to be trusted. If the metadata is incorrect or tampered with, it could lead to incorrect function calls, potentially causing erroneous approvals or rejections.

Contract Metadata​

Ink! metadata serves as a language-agnostic descriptor for a contract. It is primarily intended for use by third-party tools such as user interfaces and block explorers, enabling them to correctly call contract functions and interpret events. The metadata is generated when a contract is built using the cargo contract build command and can be found in the contract’s target directory under the name <contract-name\>.json.

The metadata is defined by several required keys: source, contract, and abi (Application Binary Interface). It may also contain optional user-defined metadata.

The abi of a smart contract is a crucial piece of information that describes how to interact with the contract. It includes details about the contract’s functions, their inputs and outputs, events, and more. In essence, the abi serves as a blueprint for interacting with a contract.

• The source key provides information about the contract’s Wasm code, including the hash, language, and compiler used.
• The contract key offers additional metadata about the contract, such as its name, version, and authors.
• The abi key contains the raw JSON of the contract’s abi metadata, generated during contract compilation.

The Challenge​

In the context of a multisig contract, the abi becomes even more important. Owners of the multisig contract need to be able to decode transactions and understand what they’re approving or rejecting. Without the abi, the raw transaction data is just a string of bytes that’s difficult to interpret.

Non-determinism in ink! contract builds​

The build process of ink! contracts is subject to non-determinism due to several factors. These factors encompass the version of Rust, enabled features, cargo-contract version, number of optimization passes, and build mode. As a result, the final product of the contract build can vary.

The non-deterministic nature of the build process poses challenges for contract verification. Establishing trust in a contract’s reliability becomes difficult when the build outcome is not consistent across different operating systems and architectures. Trust is crucial for users who rely on the contract’s functionality and need assurance of its integrity.

The presence of non-determinism in ink! contract builds needs careful consideration during the verification process. Extra precautions and thorough testing may be required to ensure that the contract behaves as intended across different build environments. By addressing the challenges posed by non-determinism, it becomes possible to enhance trust in ink! contracts and promote their reliability for users.

The Challenge​

The inherent non-determinism in the build process of ink! contracts presents a significant hurdle for owners of a multisig contract intending to interact with an arbitrary contract. Despite having the same source code, each owner could independently compile the contract and end up with a distinct wasm and code hash. This discrepancy makes it impossible for any owner to conclusively demonstrate that they’ve generated an identical contract from the same source code. They might end up with slightly different ABIs, leading to inconsistencies when decoding transactions. Consequently, this could lead to confusion regarding the purpose of a transaction, potentially causing erroneous approvals or rejections.

To address this issue, it’s important to have a secure way to exchange the ABI among the owners. This could be done through a secure communication channel, or by hosting the ABI on a trusted server. The key is to ensure that all owners are using the exact same ABI to decode transactions.

However, it’s important to note that both of these solutions inherently involve a degree of trust. If the ABI is exchanged directly among the owners, each owner must trust that the others are providing the correct and unaltered ABI. Similarly, if the ABI is hosted on a trusted server, all owners must trust that the server is secure, reliable, and providing the correct ABI.

Cross-Contract Calls​

Cross-contract calls in ink! contracts enable the invocation of messages and constructors of other contracts on the same chain. To facilitate such calls, ink! provides the CreateBuilder and CallBuilder interfaces. The CreateBuilder is used to instantiate already uploaded contracts, while the CallBuilder allows for calling messages on instantiated contracts.

To instantiate a contract using the CreateBuilder, a reference to the contract and relevant parameters are required. For the instantiation process, the code hash, gas limit, transferred value, constructor arguments and salt bytes are needed.

Once a contract is instantiated, the CallBuilder provides the means to make calls to other contracts. It supports regular Calls, where an already instantiated contract is specified. For the invocation of a call, the contract address, gas limit, transferred value, selector, message arguments and some optional flags are needed.

In the context of the multisig contract, only the CallBuilder interface will be utilized. This is because the multisig contract is designed to interact with any arbitrary smart contract already deployed on the blockchain, rather than instantiating new contracts. By using the CallBuilder, the multisig contract can make calls to any other contract on the same chain.

Example: In the following example, we initially assume that the contract we’re interacting with uses the default selector for each function:

let result = build_call::<DefaultEnvironment>()
  .call(AccountId::from([0x42; 32]))
  .gas_limit(0)
  .transferred_value(0)
  .exec_input(
    ExecutionInput::new(Selector::new(ink::selector_bytes!("add_owner")))
      .push_arg(&[0x10u8; 32])
  )
  .returns::<Vec<u8>>()
  .invoke();

However, in practice, we cannot make this assumption. Instead, we need to use the provided selector directly:

let result = build_call::<DefaultEnvironment>()
  .call(AccountId::from([0x42; 32]))
  .gas_limit(0)
  .transferred_value(0)
  .exec_input(
    ExecutionInput::new([170,170,170,170].into())
      .push_arg(&[0x10u8; 32])
   )
  .returns::<Vec<u8>>()
  .invoke();

Furthermore, we won’t know in advance how many arguments the function will have. Therefore, we can only push arguments once as an opaque Vec of u8s. The arguments will need to be transformed on the frontend from their arbitrary types to a concatenated vec of u8s:

struct InputArgs<'a>(&'a [u8]);

impl<'a> scale::Encode for InputArgs<'a> {
  fn encode_to<T: Output + ?Sized>(&self, dest: &mut T) {
    dest.write(self.0);
  }
}

let result = build_call::<DefaultEnvironment>()
  .call(AccountId::from([0x42; 32]))
  .gas_limit(0)
  .transferred_value(0)
  .exec_input(
    ExecutionInput::new([170,170,170,170].into())
      .push_arg(InputArgs(&[1,2,3,4]))
  )
  .returns::<Vec<u8>>()
  .invoke();

It is important to note that message arguments should match the order and type specified in the function signature. Compile-time feedback is not available for call failures, and errors can only be detected at runtime.

Both the CreateBuilder and CallBuilder offer error handling through the try_instantiate() and try_invoke() methods, respectively. These methods allow developers to handle errors from the execution environment and the programming language itself.

By utilizing these builders, ink! contracts can effectively interact with other contracts on the chain, facilitating the exchange of messages and constructor invocations.

The Challenge​

The challenge lies in generating the raw bytes needed as arguments for the transaction that is intended to be submitted. Given that we won’t know in advance how many arguments the function will have, the frontend will need to transform these arguments from their arbitrary types into a concatenated vector of u8s. This process involves encoding the arguments in a way that matches the order and type specified in the function signature.

Conclusion​

This comprehensive research article has delved into the intricacies of the Contract Pallet. The motivation behind this study was to gather the necessary information to develop a multi-signature wallet using the ink! smart contract language.

The article has explored the differences between parachains and smart contracts, the role of the Contract Pallet, and the limitations of smart contracts. It has also examined the use of Ink! as a language to write smart contracts, the challenges of storage layout design, the importance of selectors, the role of contract metadata, and the implications of non-determinism in Ink! contract builds.

The research has highlighted several challenges that need to be addressed. These include handling sub-call failures, securely obtaining and verifying contract metadata, dealing with non-determinism in contract builds, and generating the raw bytes needed as arguments for transactions.

In conclusion, the research has provided a solid foundation for the development of the multi-sig and has contributed to the broader understanding of smart contracts in the Substrate ecosystem. It has also highlighted the need for further research and development to address the challenges identified.

Reentrancy is a common issue in smart contracts where a contract calls another contract before it resolves its state. This can lead to unexpected behavior and potential security vulnerabilities. In our case, we needed to allow for reentrancy to enable our contract to change its own state — such as changing an account or the threshold.

We also encountered a problem with circular calls between multiple contracts. In our scenario, we had two contracts, A and B. We could successfully make cross-contract calls from A to B and from B to A. However, we faced a problem when trying to make a circular cross-contract call from A to B and then back to A. This led to a failed transaction, indicating a potential limitation or issue in the ink! framework.

The Solutions​

Leveraging the Flush Trait and Understanding Circular Calls​

After some research and discussions on the Substrate StackExchange, we found potential solutions to our problems.

For the reentrancy issue, we needed to manually reload the contract state after a reentrant call to ensure that it was up-to-date. This was achieved by using the Flush trait from the OpenBrush library. This code checks if the transaction allows for reentry and if the transaction is being called by the same contract. If both conditions are met, it reloads the contract state using the self.load() function. This ensures that the contract state is up-to-date after a reentrant call.

if tx.allow_reentry && tx.address == self.env().account_id() {
  self.load();
}

However, this solution came with a trade-off. To use the Flush trait from openbrush, we had to downgrade our ink! version to 4.1.0. This was a necessary step to ensure the security and consistency of our contract.

For the circular call issue, we realized that ink! might have limitations when it comes to circular calls between multiple contracts. Our tests showed that a circular call from A to B and then back to A failed, while a call from A to B and then to a third contract C was successful. This suggests that developers need to be aware of potential limitations when designing their contracts and consider alternative approaches when necessary.

Conclusion​

A Step Forward in Our Blockchain Journey​

Overcoming these reentrancy and circular call challenges was a significant milestone in our journey at Protofire. It not only helped us progress with our multisig smart contract but also deepened our understanding of the intricacies of smart contract development.

We hope that sharing our experience will help other developers facing similar challenges. As we continue to explore the possibilities of blockchain technology, we remain committed to sharing our learnings and contributing to the growth of this exciting field.

Remember, the path to innovation is often riddled with challenges. But as we’ve learned at Protofire, these challenges are just opportunities for learning and growth.