Alternative solutions

Before choosing Substrate, we studied several alternatives, searching for an optimal for the team while meeting the project's requirements. The solution had to be distributed to allow the addition of new validators in a decentralized way. The signature must involve most but not necessarily all of the signors, allowing space for malicious or offline nodes.

1. EVM

EVM (Ethereum Virtual Machine) is a decentralized protocol for executing smart contracts on the Ethereum network. While it has played a pivotal role in the blockchain ecosystem, it has faced challenges regarding protocol security breaches. These vulnerabilities within the EVM's core node code have led to significant incidents in the past, posing risks to the stability and security of the network.

1.1 Security Breaches

The Ethereum Virtual Machine (EVM) has experienced notable security breaches in the past, with each incident highlighting the vulnerabilities within the EVM protocol. These include the infamous "DAO Attack" in 2016, where an attacker exploited a vulnerability in the DAO smart contract code, leading to a contentious hard fork in the Ethereum network. Additionally, the "Parity Multisig Wallet Bug" of 2017 resulted in the loss of millions of dollars due to a critical flaw in the Parity Wallet's smart contract.

1.2. Not modular

One primary reason for rejecting the use of EVM in our XP.NETWORK NFT bridge project is the need for modularity in EVM nodes. EVM nodes are not inherently designed to be modular, making it challenging to customize and adapt them to our specific project requirements. This lack of modularity can limit the flexibility and efficiency of our node implementation.

1.3. Poor development documentation

Furthermore, the decision to opt for Substrate over EVM is also influenced by the issue of poor development documentation within the EVM ecosystem. Inadequate documentation can impede the development process, increase the learning curve for developers, and lead to potential errors or inefficiencies in implementing our decentralized node infrastructure.

2. Solana

Solana nodes offer a robust framework for achieving decentralized consensus; however, there is a notable limitation in the Solana network, where a maximum of seven nodes can participate in the voting process at any given time.

2.1 Security Breaches

In August 2022, an attack on the Solana blockchain led to the compromise of over 7,700 software wallets, including users of Slope, Phantom, Solflare, and Trust Wallet, resulting in losses of approximately $5.2 million in SOL, NFTs, and various Solana-based tokens. The attack's precise method, suspected to involve a private key compromise, is under investigation, with potential vulnerabilities in wallet software, such as supply chain attacks, browser zero-day flaws, or faulty random number generators, considered contributing factors. Nonce reuse bugs are also under scrutiny as a possible cause for the compromise of private keys.

2.2. Not modular

One of the notable limitations of the Solana node implementation is its lack of modularity. Unlike other blockchain networks that offer a modular architecture where self-consistent packages can be easily added or removed from a core node, Solana's node architecture is more monolithic. Structural changes or customizations to the node can be relatively complex and inflexible.

2.3. Poor development documentation

Developing on the Solana network can be challenging due to the need for comprehensive and well-structured documentation for node developers. The absence of clear and detailed documentation can make it difficult for developers to navigate the existing code base, add new features, or tailor the node to suit specific use cases. This lack of documentation increases the learning curve for developers and hampers the efficiency of development efforts.

3. EOS

EOS is a blockchain platform renowned for its capabilities as a framework for building decentralized applications and custom blockchains. Its technological stack features a delegated proof-of-stake (DPoS) consensus algorithm, prioritizing scalability and high transaction throughput, making it suitable for enterprise-grade applications. EOS provides a web-based toolkit for smart contract development, EOSIO, and uses the C++ programming language. It boasts a few significant advantages, including rapid transaction processing, low latency, and feeless transactions, which make it an appealing choice for applications requiring real-time interactions.

3.1 Security Breaches

EOS has experienced significant security breaches, with EOSBet, a gambling decentralized application (dApp), falling victim to two notable hacks. The first hack occurred on October 15, 2018, resulting in the loss of at least $338,000 in EOS tokens, followed by a similar attack in September 2018. Other EOS-based dApps like DEOS and EOS.WIN faced similar issues. These hacks were possible due to vulnerabilities in how EOS contracts interacted with the eosio.token contract. By exploiting a bug in the dispatch transfer function, hackers could send tokens from one account to another, and the recipient contract would mistakenly process it as a legitimate transaction from eosio.token. It allowed malicious actors to manipulate the system and execute unauthorized actions. The lack of proper validation and documentation for handling such transfers within EOS contracts contributed to these vulnerabilities and their exploitation. However, the need for significant computational resources to run EOS nodes may be a barrier for some participants.

3.2. Small development community

EOS has grappled with maintaining a relatively small developer community, which can be a significant obstacle when creating complex systems like new consensus mechanisms. The intricacies of developing and fine-tuning innovative consensus mechanisms often require expertise and experience. Due to the limited developer base, Developers need help seeking assistance or troubleshooting issues. Smaller communities also result in slower response times for problem resolution and hinder the collaborative development of robust consensus protocols.

3.3. Centralized

EOS has faced criticism for its perceived centralization due to several factors. One key point of contention is its delegated proof-of-stake (DPoS) consensus mechanism, which relies on a relatively small number of elected block producers (21 in the mainnet) responsible for validating transactions and maintaining the network. This limited number of block producers raises concerns about the concentration of power and decision-making among a select few, potentially undermining the blockchain's decentralization ideals. EOS's governance model has also been criticized for lacking transparency and inclusivity, with decisions made by a small group of token holders. These factors have fueled the criticism that EOS may not be as decentralized as some other blockchain networks, as governance and validation power can become concentrated in the hands of a few entities.

4. Hyperledger

Hyperledger is a prominent framework for developing blockchain nodes, emphasizing enterprise-grade solutions and collaboration. Its technological stack features modular components, including Hyperledger Fabric, Sawtooth, and Besu, each tailored to specific use cases. Hyperledger leverages various programming languages, such as Go, Java, and Rust, allowing developers flexibility. Its key advantages include a strong focus on privacy and permissioned networks, making it a preferred choice for businesses requiring control over who participates. Furthermore, it encourages an open-source and collaborative approach, ensuring the quality and security of the codebase. However, Hyperledger's cons include a steeper learning curve, as it caters to complex enterprise solutions, which might be challenging for newcomers. Additionally, its emphasis on permissioned networks may limit its applicability for public, fully decentralized blockchain use cases.

4.1 Complex learning curve

Hyperledger's complex learning curve primarily stems from its focus on building enterprise-grade, permissioned blockchain solutions. It involves a depth of features, configurations, and tools designed to meet business use cases' unique and intricate requirements. Hyperledger's modular architecture and the diversity of programming languages it supports makes it highly customizable, but this versatility can be daunting for newcomers. Developers need to master various components, including Hyperledger Fabric's chain code, channels, endorsing peers, Sawtooth's transaction families, or Besu's EVM compatibility, depending on the chosen framework. Additionally, the need for understanding enterprise-level security and permission models adds another layer of complexity.

4.2. Hardware resource-intensive

Hyperledger Fabric, one of its prominent frameworks, can involve multiple nodes, each performing various tasks like endorsing, validating, and committing transactions, placing a significant load on the underlying infrastructure. Additionally, the need for encryption, key management, and consensus mechanisms can further strain hardware resources.

5. Corda

Corda is another blockchain framework tailored for building blockchain nodes and distributed applications within the financial and enterprise sectors. Its key feature is its focus on facilitating secure and private transactions between parties in a business network. Its core technological components, such as the Corda Node, offer the ability to interact with other nodes securely, and the Corda Network facilitates the exchange of data and assets between participants. Corda also provides strong privacy and data segregation features, enabling businesses to transact confidentially while still complying with regulatory requirements. Its advantages include robust security and confidentiality, scalability, and flexibility in managing complex financial transactions. However, it may be considered less suitable for public, fully decentralized blockchain use cases due to its primary focus on private, permissioned networks.

5.1 Complex learning curve

Even developers with blockchain expertise might need help with transitioning to Corda due to its distinctive features. Corda's strong emphasis on privacy and data sharing, Kotlin programming language, notary-based consensus mechanism, and financial focus sets it apart from traditional public blockchains. Based on flows and contract states, its smart contract approach differs from Ethereum's approach, necessitating developers to adapt their mindset and coding practices. Corda's complexities are vital for addressing the intricate regulatory and compliance requirements of the financial and enterprise sectors, but these intricacies contribute to the initial learning curve, making it distinct from other blockchain frameworks. Corda primarily uses Kotlin as its programming language. While Kotlin is highly expressive and interoperable with Java, it may be less familiar to developers who predominantly use languages like Rust or Go (Hyperledger Fabric). Adjusting to Kotlin can add an initial learning curve.

5.2. Fungible tokens specialized

Corda is particularly tailored for the financial and enterprise sectors with intricate regulatory and compliance requirements. Developers must understand these industry nuances and integrate them into their Corda-based solutions.

5.3. Small development community

Corda's relatively smaller developer community can present challenges for new developers. The limited pool of Corda experts means newcomers may need help finding readily available resources, documentation, and community support for troubleshooting issues or seeking guidance. The scarcity of Corda-focused educational materials and community-driven forums can potentially result in a longer learning curve. Furthermore, the smaller developer base may lead to slower development of third-party tools and plugins, limiting the ecosystem's expansion.

6. Tezos

Tezos, a versatile and innovative blockchain platform, is a compelling framework for developers of blockchain nodes. Its distinctive self-amending protocol sets Tezos apart, which allows the network to evolve and upgrade without requiring contentious hard forks. Tezos provides an environment for creating decentralized applications, smart contracts, and custom blockchain nodes while emphasizing security, formal verification, and on-chain governance. With its flexible architecture, the Tezos blockchain is engineered to meet the demands of diverse use cases, offering developers the tools to craft decentralized solutions that can adapt, scale, and remain secure over time. Its unique features and developer-friendly approach make Tezos an enticing option for those seeking to build robust and forward-looking blockchain applications.

6.1 Complex node upgrades

In the Tezos ecosystem, validating nodes, or "backers," play a pivotal role in the network's operation. However, one notable challenge developers face is the need to update backers. Tezos is known for its frequent protocol updates, yet often, these updates come with limited or insufficient documentation on what needs to be updated and how to go about it. Additionally, the number of components required for a backer to function optimally can change frequently, further complicating the maintenance process. These challenges can be particularly daunting for developers without access to insights from Tezos insiders, as staying up to date with the rapidly evolving ecosystem and ensuring the seamless operation of validating nodes can be an intricate and demanding endeavor. However, in our solution, we want to upgrade the nodes in a validator-friendly way.

6.2 Outdated documentation

Frequent node upgrades in the Tezos blockchain network have introduced a significant challenge for developers: the perpetual disconnect between available documentation and the evolving codebase. With Tezos' commitment to continuous improvement and self-amendment, documentation can swiftly become obsolete and misaligned with the latest code iterations. This incompatibility presents a formidable hurdle for development, as attempting to build upon or maintain a system without accurate and up-to-date documentation is daunting and inefficient. The need for comprehensive, synchronized documentation that aligns with Tezos' evolving codebase is crucial for developers seeking to work effectively within the ecosystem, as the absence of such resources can hinder the development process and lead to uncertainty in project execution.

6.3 Small development community

Tezos boasts a vibrant but relatively small developer community, which can be both a strength and a challenge for node developers. This community's close-knit and supportive nature fosters collaboration and the exchange of ideas. However, the smaller size of the community also means that there are limited resources and specialized expertise available for node developers seeking to tailor the network to specific, niche needs, such as distributed bridge transaction validation.

7 Cosmos SDK

The Cosmos SDK serves as a versatile framework for blockchain development, prized for its modular architecture that enables the creation of custom blockchains tailored to specific needs. Notable advantages of Cosmos include its exceptional interoperability, facilitated by the Inter-Blockchain Communication (IBC) protocol, which fosters a connected blockchain ecosystem. The Cosmos SDK's proof-of-stake (PoS) consensus mechanism enhances scalability and efficiency, particularly valuable for applications demanding rapid and cost-effective transactions. Furthermore, an active developer community provides a wealth of resources and support, making it an attractive choice for those looking to build blockchain solutions with flexibility and innovation at the core.

7.1 Complex learning curve for our team

Since our development team is already familiar with Rust and Substrate framework, transitioning to the Cosmos SDK may involve a learning curve due to several distinctions in the technological stack, architectural design, and conceptual approaches:

Language

While Substrate uses Rust as its primary language, the Cosmos SDK predominantly uses Go. Developers familiar with Rust may need to adjust to Go's syntax and conventions.

Modularity

Substrate is known for its highly modular design, allowing developers to customize and add or remove components easily. In contrast, the Cosmos SDK also offers modularity, but differs in how modules and components are structured, necessitating adaptation.

Architecture

Substrate utilizes a unique, runtime-based architecture that separates the core blockchain logic from the application-specific logic. The Cosmos SDK follows a different architectural model, which requires understanding and adaptation.

Consensus Mechanism

Substrate provides flexibility in choosing a consensus algorithm, while the Cosmos SDK often relies on Tendermint as the default consensus mechanism. This shift may entail a transition in the understanding of consensus protocols.