<p><em><strong>In this blog post, we’ll delve into the significant changes Mainsail introduces and how it distinguishes itself from the current Core version. This blog post does not yet contain information about the EVM and is an overview of pure Core vs Mainsail changes. Let’s dive right in.</strong></em></p><h2 id="header-0">Key Changes in Mainsail</h2><p>The most notable changes in Mainsail compared to the latest Core version include:</p><ul><li>Introduction of a new BFT consensus mechanism with instant finality.</li><li>Increase in the number of active validators from 51 to 53.</li><li>Implementation of state snapshots to expedite synchronization.</li><li>Removes the necessity for an external database configuration, except for the optional public API.</li><li>Separation of the public API into a separate process for improved scalability.</li><li>Modernization of the codebase with the adoption of ES modules.</li><li>Switch to pnpm as the primary package manager for enhanced dependency management.</li><li>Change in the project’s license from MIT to GPLv3.</li></ul><p>These changes collectively enhance the security, scalability, and performance of Mainsail, positioning it as a robust and innovative blockchain solution.</p><h2 id="header-1">Technical Comparison</h2><p>The technical differences between Mainsail and the latest Core version are:</p><p>FeatureCore V3MainsailLedger DatabasePostgreSQLLMDBAPI DatabasePostgreSQLPostgreSQLIsolated Public APINoYesBlock FinalizationNoYesBlock RollbacksYesNoValidators5153Block Time (sec)8&gt;&#61;8 (dynamic)State SnapshotsNoYesNodeJS Version&gt;&#61;14&gt;&#61;20Ubuntu Version&gt;&#61;18&gt;&#61;22Package ManagerYarnpnpmTest FrameworkJestUvu</p><h2 id="header-2">Project Insights</h2><p>Let’s go over some of the technical, codebase, and general changes that are going to be in Mainsail.</p><h3 id="structure-packages">Structure &amp; Packages</h3><p>Mainsail’s code originates from the <a href="https://github.com/arkecosystem/core" rel="noopener noreferrer nofollow">Core V3 repository </a>. However, there are noticeable changes to the project structure that can be observed at a glance. The project is split up into 72&#43; packages compared to the 19 packages found in the V3 repository.</p><p>Additional packages are a result of splitting the crypto, core-transactions, and api packages.</p><h4>Crypto</h4><p>The crypto package has undergone significant refactoring and was split into separate address, key-pair, hash, and signature packages. Mainsail allows blockchain creators to implement custom crypto packages or use existing implementations from the Mainsail repository.</p><p>The following options are available at this point:</p><ul><li><strong>Key-pair</strong>: BLS12-381, ECDSA, Ed25519, Schnorr</li><li><strong>Signature</strong>: BLS12-381, ECDSA, Ed25519, Schnorr, Schnorr-secp256k1 (deprecated)</li><li><strong>Address</strong>: Base58, Bech32, Bech32m, Keccak256, SS58</li><li><strong>Hash</strong>: Bcrypto, Noble, Wasm</li></ul><p><em><strong>Note:</strong></em> <em>Some combinations of packages might not work.</em></p><h4>Transactions</h4><p>The transaction package was split into individual transaction packages. We currently support:</p><ul><li>Transfer</li><li>Multipayment</li><li>Multisignature registration</li><li>Validator registration</li><li>Validator resignation</li><li>Username registration</li><li>Username resignation</li></ul><p>New second-signature registrations are no longer possible. Existing second signature-enabled wallets will still be supported.</p><p><em><strong>Note:</strong></em> <em>Core V3 distinguishes between v1 and v2 transactions. Mainsail only supports v2 while labeling it as v1. In other words, a Mainsail v1 transaction is equivalent to a Core v2 transaction, and Core v1 transactions are no longer supported.</em></p><h4>API</h4><p>The Public API is no longer part of the core process but is now a separate process known as mainsail-api.</p><p>The Mainsail node still exposes a single API endpoint for sending transactions found in api-transaction-pool.</p><p>Optionally, api-development can be enabled for debugging purposes. It is recommended to keep this API disabled on a public network.</p><p>Code changes result in the following new packages:</p><ul><li><strong>api-common</strong>: building blocks for the API including common plugins, base server, JSON-RPC, …</li><li><strong>api-http</strong>: API endpoints for the Public API.</li><li><strong>api-database</strong>: database package for PostgreSQL used by Public API.</li><li><strong>api-sync</strong>: sync service that seeds PostgreSQL database from Mainsail process with data (transactions, blocks, wallets, …).</li><li><strong>api-transaction-pool</strong>: API on the mainsail node for receiving transactions.</li><li><strong>api-development</strong>: development API that allows insight into Mainsail, consensus, state, and ledger.</li></ul><h4>Strategy Packages</h4><p>Other packages have also been split up, and sometimes they can be used to provide different <strong>strategies</strong> and <strong>implementations</strong> to Mainsail. As seen from the crypto example, you can build up a Mainsail blockchain using different variants. We provide some of the possible variants, but other developers can also implement their implementations and pack them as plugins.</p><p>Logger</p><p>Users can switch from the default pino logger to the winston implementation.</p><p>Fees</p><p>Users have the option to select between Static fees (a predefined fee for transactions) and Managed fees (fees based on transaction length). More options will be investigated in the future with the implementation of the EVM.</p><p>Validator Set</p><p>The Validator Set is a fundamental building block in Mainsail that provides a list of <strong>active validators</strong> utilized by consensus and block processing. <strong>Active validators</strong> represent a subset of <strong>registered validators</strong> responsible for block creation and signing. Mainsail defaults to using 53 active validators.</p><p>Different strategies can determine the active validator set. Mainsail offers 2 options:</p><ul><li><strong>Static</strong>: Utilizes genesis validators that cannot be changed. Useful during development phases, but not advisable for use in production environments.</li><li><strong>Vote Weighted</strong>: Recalculates the validator set every validator round (53 blocks) based on the vote balance, closely resembling the mechanism in Core V3.</li></ul><h4>License</h4><p>Mainsail is licensed under the <a href="https://raw.githubusercontent.com/ArkEcosystem/mainsail/develop/LICENSE" rel="noopener noreferrer nofollow">GNU General Public License v3.0 </a>.</p><h3 id="toolchain">Toolchain</h3><p>The project continues to use TypeScript as its primary language. It’s a pnpm monorepo split into multiple packages, also known as <a href="https://pnpm.io/workspaces" rel="noopener noreferrer nofollow">workspaces </a>.</p><p>We transitioned from <a href="https://yarnpkg.com/" rel="noopener noreferrer nofollow">yarn </a> to <a href="https://pnpm.io/" rel="noopener noreferrer nofollow">pnpm </a> package manager due to known issues with yarn on V3, including problems with dependencies using different versions, as well as performance and disk space improvements.</p><p>We utilize <a href="https://lerna.js.org/" rel="noopener noreferrer nofollow">Lerna </a> as the primary build system for monorepos. The new Lerna version employs <a href="https://nx.dev/" rel="noopener noreferrer nofollow">NX </a> in the background. Scripts are parallelized when possible to improve build times, resulting in faster build times on systems that utilize multiple processor cores.</p><p>To provide browser builds for most Mainsail packages, we ported the entire codebase to <a href="https://nodejs.org/api/esm.html#modules-ecmascript-modules" rel="noopener noreferrer nofollow">ES modules </a>. This enables signing and interaction with Mainsail from a web browser.</p><h4>For Developers</h4><p>If you plan to make changes to the project, develop plugins, or maintain a fork, we recommend using a code editor or IDE with extensions that support <a href="https://prettier.io/" rel="noopener noreferrer nofollow">Prettier </a>, <a href="https://eslint.org/" rel="noopener noreferrer nofollow">ESLint </a>, and <a href="https://editorconfig.org/" rel="noopener noreferrer nofollow">EditorConfig </a> files.</p><p>We recommend <a href="https://code.visualstudio.com/" rel="noopener noreferrer nofollow">Visual Studio Code </a> with the following extensions:</p><ul><li><a href="https://marketplace.visualstudio.com/items?itemName&#61;EditorConfig.EditorConfig" rel="noopener noreferrer nofollow">EditorConfig for VS Code </a></li><li><a href="https://marketplace.visualstudio.com/items?itemName&#61;dbaeumer.vscode-eslint" rel="noopener noreferrer nofollow">ESLint </a></li><li><a href="https://marketplace.visualstudio.com/items?itemName&#61;esbenp.prettier-vscode" rel="noopener noreferrer nofollow">Prettier - Code formatter </a></li></ul><h3 id="tests">Tests</h3><p>The <a href="https://www.npmjs.com/package/uvu" rel="noopener noreferrer nofollow">Uvu </a> test runner has replaced <a href="https://jestjs.io/" rel="noopener noreferrer nofollow">Jest </a> in Mainsail. Uvu is lightweight and offers better performance compared to Jest.</p><p>While Jest tends to be an all-in-one framework for testing, uvu is much smaller and focuses specifically on being a test runner. Additional packages are utilized to support tests:</p><ul><li><a href="https://www.npmjs.com/package/sinon" rel="noopener noreferrer nofollow">sinon </a>: Provides test spies, stubs, and mocks.</li><li><a href="https://www.npmjs.com/package/nock" rel="noopener noreferrer nofollow">nock </a>: Facilitates HTTP server mocking.</li><li><a href="https://www.npmjs.com/package/esmock" rel="noopener noreferrer nofollow">esmock </a>: Offers advanced dependency mocking capabilities.</li><li><a href="https://www.npmjs.com/package/c8" rel="noopener noreferrer nofollow">c8 </a>: Used for code coverage analysis.</li></ul><h2 id="header-3">Consensus</h2><p>Mainsail comes with a Byzantine Fault Tolerance (BFT) consensus mechanism inspired by Tendermint. You can learn more about its internals and check consensus pseudocode in the article: <a href="https://arxiv.org/pdf/1807.04938.pdf" rel="noopener noreferrer nofollow">The latest gossip on BFT consensus </a>.</p><h3 id="block-finality">Block Finality</h3><p>The new consensus mechanism in Mainsail introduces block <strong>finality</strong> with the last block. Once a block is <em>committed</em>, it becomes <strong>irreversible</strong>. This commitment is acknowledged by the majority of active validators who have seen and confirmed the block.</p><p>As a consequence of this feature, rollback becomes impossible. Mainsail removes all logic related to rollback. Transactions that are included in the last block are considered final and cannot be reverted.</p><p>Forking at the blockchain level is prevented as long as there are more than 2/3 of honest validators (Byzantine Fault Tolerance) participating in the network.</p><p>However, in the rare event of a network fork, resolution can still be achieved through social consensus.</p><h3 id="block-cycle">Block Cycle</h3><p>A block can only be accepted by the network under certain rules. Active validators participate in the block acceptance process on every cycle. A block is deemed acceptable when more than 2/3 of validators have seen and confirmed it through a process comprising two vote phases and a commit phase.</p><h4>Proposal</h4><p>Each attempt to accept a block at a specific height is termed a <strong>round</strong>. The round number increases with each attempt to produce a block by a proposer, one of the active validators. On each successful block commit, this round is reset to 0.</p><p>Before proposing a new block, there is a minimal delay (default 8000 ms) to allow for enough processing time between blocks. After this delay, the proposer prepares a proposal message containing the new block and broadcasts it.</p><p>The proposer is chosen from the list of active validators, and with every round and height change, a new proposer is selected.</p><h4>Prevote</h4><p>Validators that accept a proposal with a valid block broadcast a prevote message containing the <strong>blockId</strong>. If a block is invalid or not received within the predefined time window, validators broadcast a prevote message with a <strong>null</strong> value.</p><h4>Precommit</h4><p>The consensus proceeds to the precommit stage when a validator receives more than 2/3 of prevotes. If a validator does not receive sufficient prevotes in time, it broadcasts a precommit message with a <strong>null</strong> value. Similarly, if a validator receives more than 2/3 of null prevotes, it broadcasts a precommit message with <strong>null</strong>.</p><p>If a validator receives more than 2/3 of prevotes with a valid <strong>blockId</strong>, it broadcasts a precommit message with the <strong>blockId</strong>.</p><h4>Commit</h4><p>When a node receives more than 2/3 of precommits with a valid <strong>blockId</strong>, the block is committed and added to the ledger. The consensus process advances to the next block height.</p><p>If a node receives more than 1/3 of null messages, indicating the block’s non-acceptance, a new proposer will provide a block for the next attempt without increasing the height.</p><h4>Extra Notes</h4><p>The next proposer has the option to either re-propose the same block or propose a new block, depending on the node’s lock status. This overview provides a basic understanding of the algorithm, but there are additional complexities such as locks and timeouts that are not covered here.</p><p>Timeout values for each stage are defined in milestones (stageTimeout &#61; 2000ms). Additionally, the stage timeout is increased by a predefined delta value (stageTimeoutIncrease &#61; 2000ms) each unsuccessful block attempt (round) to mitigate message delays and address network fragmentation.</p><h3 id="bls12-381">BLS12-381</h3><p>Validators register BLS12-381 public keys in the validator registration transaction. They utilize BLS12-381 private keys to sign consensus messages, including proposal, prevote, and precommit.</p><p>For a more in-depth explanation of how BLS signatures work, refer to <a href="https://hackmd.io/&#64;benjaminion/bls12-381" rel="noopener noreferrer nofollow">this resource </a>.</p><h4>Aggregation</h4><p>The main reason we opted for this type of signatures, and that we want to highlight, is because they offer a special property called aggregation amongst other important advantages over Schnorr. This makes them more suitable for a BFT consensus. Message signatures can be aggregated into a single signature, resulting in a significantly smaller commit size as we store only a single signature instead of 53 signatures.</p><p>To verify an aggregated signature, a node can provide a list of public keys from validators that were used in the signature aggregation.</p><h2 id="header-4">Database</h2><p>The primary database used in Mainsail is <a href="https://www.npmjs.com/package/lmdb" rel="noopener noreferrer nofollow">LMDB </a>, a high-performance key-value store. LMDB stores full blocks by height and block ID.</p><p>LMDB offers superior performance and replaces <a href="https://www.postgresql.org/" rel="noopener noreferrer nofollow">PostgreSQL </a> for all non-API use cases in Mainsail.</p><p>The core Mainsail instance doesn’t require additional database setup as known from V3. LMDB is provided as an npm package and utilizes local disk storage.</p><h3 id="state">State</h3><p>Since LMDB only stores full blocks, the state is bootstrapped on every boot by reprocessing all blocks.</p><p>To expedite this process, the current state is exported to disk every N blocks (1000 by default), which includes wallet data. During bootstrap, the node reads the most recent export it can find and skips reapplying blocks that are already part of the snapshot.</p><p>This speeds up node synchronization and bootstrap, preventing slowdowns as the chain progresses.</p><p>State refers to an in-memory representation of wallets and consensus-related data. Wallets are objects with different attributes. These attributes hold various kinds of values (boolean, string, custom objects, etc.). Developers can extend wallet or state attributes to support custom implementations. New attributes are automatically handled by the state exporter and importer.</p><h2 id="header-5">API (Optional)</h2><p>The Public API has been moved to a separate process. When optionally enabled, the node process syncs all data via api-sync to a PostgreSQL database on each commit. There is no direct communication between the API and the node process. Because of this, the first time the API is enabled a full sync from 0 is required. The Mainsail node provides data while the API is serving it by reading it from the database.</p><p>The Mainsail API aims to maintain compatibility with V3 data models but may add additional/new endpoints as needed.</p><h2 id="header-6">Conclusion</h2><p>In conclusion, Mainsail represents a substantial advancement over Core V3, with notable improvements in consensus algorithm, database management, and modular architecture. These enhancements are designed to elevate performance, scalability, and the overall developer experience. We invite you to join us on this Mainsail development journey, and we hope you’ve gained valuable insights from this overview.</p><h2 id="header-7">Follow on Twitter (X)</h2><p>Follow us on <a href="https://x.com/ArkEcosystem" rel="noopener noreferrer nofollow">X </a> (formerly Twitter) and keep checking the blog to stay up-to-date on all ARK-related updates. We also post a weekly development report so you can easily see what we’ve been up to and follow along our journey towards making your decentralized future a reality.</p>

Exploring Core vs Mainsail: What's Different?

Table of Contents

ARK Ecosystem

Other articles published on Apr 4, 2024

Nigerian court postpones detained Binance official’s hearing

Indonesia to Establish $200 Million AI Development Center in Solo

Bitcoin Cash Price Prediction: Is $1000 the next milestone?

Ethena Price Prediction: ENA Surges 22% As Analysts Say Consider This 2.0 Meme Coin For Parabolic...

BlockDAG Presale Leads THETA Price, and GALA Crypto with 20,000x ROI Potential

Crypto bull run ignites surge in job listings, salary increases

Join our free newsletter for daily crypto updates!