Damir Khabibrakhmanov

Crypto mining companies are driven by factors such as cheap electricity, favorable regulation, and stable infrastructure. Where these three factors exist, we have always seen a strong drive for Crypto/POW mining companies to centralize hashpower. Titan is using the Lumerin protocol to create solutions to the problem of rising hashpower centralization. The first will be a global decentralized peer-to-peer (P2P) marketplace whTitan Management:

• Titan Pool
• Titan Hashpower Marketplace

While, on the other hand, the Lumerin brand will refer to decentralized, open-source, public platforms, like:

• Lumerin Network
• Lumerin Proxy Node & API
• Lumerin Protocol
• Lumerin Blockchain
• Lumerin (LMR) Token
• Lumerin Walletere hashrate is a traded, liquid financial asset, allowing for increased mining profitability and capital access.

Titan Mining will remain an operating company and a leading innovator in cryptocurrency mining solutions. As a company, we will still provide powerful software and services for crypto mining at scale and offer North America’s first enterprise-grade mining pool. Additionally, from this point forward, we will dedicate many resources and efforts to support and help the open-source project, Lumerin, grow.

• Selling it in advance at a fixed price, collecting payments in a cryptocurrency or stablecoin of their preference.
• Renting out their mining equipment, granting the renter complete control over its computing power and configuration.
• Access to hashrate derivative products (futures, options, etc.)
• The possibilities are only limited by the creativity of the community. We want the Lumerin Protocol to be community-driven, which means that anyone will have the chance to build their own decentralized applications on the network. This will enable miners with several tools to manage risk, hedge against different external factors, and, most importantly, harness the true and complete power of their hashrate.

The process described above is merely the first application that will be possible to implement on the Lumerin Protocol. By tokenizing hashrate and providing a trustless, decentralized marketplace, the network opens an enormous range of possibilities for miners and investors. Miners have only two ways to earn profits at the moment. They can either mine independently or connect to a mining pool, which rewards them proportionally to their hashrate contribution against the pool’s total.

We are implementing our first-use case of the Lumerin Protocol to support a hashpower marketplace. With it, miners will be able to create smart contracts and send their computing power to them. Then, through the very same contract, a buyer can purchase and acquire the hashpower by locking the required payment. The Lumerin blockchain then records the contract, and the hashpower is re-routed from the seller’s device to the buyer’s destination. Using this technology enables the marketplace to function in a completely trustless, decentralized dynamic, making proof-of-work hashrate a tradable, liquid financial asset, unlocking mining profitability, and providing greater access to capital and investments.

Crypto mining companies are driven by factors such as cheap electricity, favorable regulation, and stable infrastructure. Where these three factors exist, we have always seen a strong drive for Crypto/POW mining companies to centralize hashpower. Titan is using the Lumerin protocol to create solutions to the problem of rising hashpower centralization. The first will be a global decentralized peer-to-peer (P2P) marketplace where hashrate is a traded, liquid financial asset, allowing for increased mining profitability and capital access.

As we advance, all aspects of the Lumerin project will be referred to and fully contained under the Lumerin community and network brand, while all commercial activities will remain under the Titan Mining brand. Titan Industries Inc. is a commercial software company that supports the Open Source project, Lumerin.

Gear is a Substrate-based smart-contract platform that enables anyone to deploy a dApp in a matter of minutes. Gear is the most cost-effective way to run smart contracts that have been compiled from many popular programming languages, such as Rust, C, C++ and many more. It ensures very minimal, intuitive and sufficient API for running both newly written and existing programs on multiple networks without having to rewrite them. Smart contracts are stored in the blockchain’s state and are invoked, preserving their state upon request.

Gear is planning on becoming a parachain in the Polkadot and Kusama networks to host smart contracts on these respective networks. This will mean that by deploying on Gear, developers would be able to take advantage of all the benefits of the Polkadot and Kusama networks and ecosystems at minimal cost.

Gear will assist with the transition to mass use of Web3 technologies by enabling the running of innovative dApps, microservices, middleware and open APIs.

As Gear uses a Substrate framework, the creation of different blockchains for specific applications is simplified. Substrate provides extensive functionality out-of-the-box and allows developers to focus on creating a custom engine on top of the protocol. This covers the most desired requirements for enterprise-ready decentralized projects.

Substrate is a modular framework that enables the creation of custom-built blockchains with consensus mechanism, core functionality and security out of the box. It is an important component of the Polkadot network and it allows every team creating a new blockchain not to waste efforts for implementing the networking and consensus code from scratch. Please refer to the Substrate Documentation for more details.

Polkadot is a next-generation Layer-0 blockchain protocol intended to unite multiple purpose-built blockchains, allowing them to operate seamlessly together at scale. The critical aspect of the Polkadot network is its ability to route arbitrary messages between chains. These messages enable negotiation channels between two parachains and allow sending asynchronous messages through it.

Using Substrate allows for a quick connection for Gear instances as a parachain into the Polkadot & Kusama networks. The Polkadot Relay Chain and Gear ultimately speak the same language - asynchronous messages. Gear’s unique asynchronous messaging architecture allows Gear to be an effective and easy-to-use parachain of Polkadot network.

Launching a blockchain was previously very expensive. It required significant efforts for building a transactions application, a distributed ledger, a consensus mechanism and a virtual machine among other things. But Gear allows dApp developers to focus on their projects rather than building and operating an entirely new blockchain from scratch.

As any blockchain system, Gear maintains distributed state. Runtime code compiled to WebAssembly becomes part of the blockchain’s storage state.

Gear ensures one of the defining features - forkless runtime upgrades. The state is also guaranteed to be finalized if a finality gadget is used.

Storage state consists of the following components:

• Programs and memory (includes program’s code and private memory)
• Message queue (global message queue of the network)
• Accounts (network accounts and their balances)

Programs are first-class citizens in the Gear network state.

Program code is stored as an immutable Wasm blob. Each program has a fixed amount of memory which persists between message-handling (so-called static area).

Programs can allocate more memory from the memory pool provided by a Gear instance. A particular program can read and write only within exclusively allocated to its memory.

Gear instance holds individual memory space per program and guarantees it's persistence. A program can read and write only within its own memory space and has no access to the memory space of other programs. Individual memory space is reserved for a program during its initialization and does not require an additional fee (included in the program initialization fee).

A program can allocate the required amount of memory in blocks of 64KB. Each memory block allocation requires a gas fee. Each page (64KB) is stored separately on the distributed database backend, but at the run time, Gear node constructs continuous runtime memory and allows programs to run on it without reloads.

Gear instance holds a global message queue. Using Gear node, users can send transactions with one or several messages to a particular program(s). This fills up the message queue. During block construction, messages are dequeued and routed to the particular program.

For a public network, protection against DOS attacks always requires gas/fee for transaction processing. Gear provides a balance module that allows to store user and program balances and pay a transaction fee.

In general, a particular Gear network instance can be defined as both permissioned and permissionless, public blockchain. In the permissioned scenario, no balance module is required.

In concurrent computing systems, “message-passing communication” means that programs communicate by exchanging messages. This has its advantages over “shared memory communication” as message passing is easier to understand than shared memory concurrency as it’s more robust and has better performance characteristics.

For inter-process communications, Gear uses the Actor model approach. The principle of the Actor model approach is that programs never share any state and just exchange messages between each other.

With the Actor model, systems consist of simultaneously functioning objects that communicate with each other exclusively by messaging. While an ordinary Actor model does not guarantee message ordering, Gear provides some additional guarantees that the order of messages between two particular programs is preserved.

The Actor model guarantees high scalability and high fault tolerance.

An Actor in the Actor model is an atomic computational unit that can send and receive messages. With Gear, an Actor is a program (smart contract) or a user that sends messages to a program. Every Actor has an internal private state and a mailbox. Communication is asynchronous, messages are popped out from the mailbox and allocated to message processing streams where they’re then processed in cycles.

When an actor receives and processes a message, the response can be the following:

• Send a message to another actor
• Create another actor
• Change its own internal state

Actors are independent, they never share any state and just exchange messages with each other.

Using the Actor model approach provides a way to implement Actor-based concurrency inside smart contract logic. It can utilize various language constructs for asynchronous programming (Futures and async-await in Rust).

Unlike classes, Actors allow only one task to access their mutable state at a time, which makes it safe for code in multiple tasks to interact with the same instance of an actor.

Asynchronous functions significantly streamline concurrency management, but they do not handle the possibility of deadlocks or state corruption. To avoid deadlocks or state corruption, async functions should avoid calling functions that may block their thread. To achieve it, they use an await expression.

Currently, the lack of normal support of async/await patterns in the typical smart contracts code brings a lot of problems for smart contract developers. Actually, achieving better control in a smart contract program flow is actually more or less possible by adding handmade functions (in Solidity smart contracts). But the problem with many functions in a contract is that one can easily get confused - which function can be called at which stage in the contract's lifetime.

Gear natively provides arbitrary async/await syntax for any programs. It greatly simplifies development and testing and reduces the likelihood of errors in smart contract development. Gear API also allows synchronous messages by simply not using await expression if the logic of the program requires it.

Individual isolated memory space per program allows parallelization of message processing on a Gear node. Number of parallel processing streams equals the number of CPU cores. Each stream processes messages intended for a defined set of programs. It relates to messages sent from other programs or from outside (user’s transactions).

For example, given a message queue containing messages targeted to 100 different programs, Gear node runs on a network where 2 threads of processing are configured. Gear engine uses a runtime-defined number of streams (equal to number of CPU cores on a typical validator machine), divides total amount of targeted programs to number of streams and creates a message pool for each stream (50 programs per stream).

Programs are distributed to separate streams and each message appears in a stream where its targeted program is defined. So, all messages addressed to a particular program appear in a single processing stream.

In each cycle a targeted program can have more than one message and one stream processes messages for plenty of programs. The result of message processing is a set of new messages from each stream that is added to the message queue, then the cycle repeats. The resultant messages generated during message processing are usually sent to another address (return to origin or to the next program).

WebAssembly is a way to run applications in programming languages other than JavaScript as web pages. Essentially, WASM is just a virtual machine that runs on all modern browsers, but whereas in the past you were required to use JavaScript to run code in a web page, WASM makes it possible to run code in browsers with programming languages other than JavaScript.

The WebAssembly Virtual Machine, or WASM for short, is proven to be faster than any alternative virtual machine because of technology peculiarities. The use of WebAssembly enables Gear’s smart contracts to compile directly into machine code and run at near-native speeds. Higher speeds means lower transaction costs and higher efficiency.

All Gear programs and smart-contract are run as WebAssembly programs. This means for example, that developers can bring their applications to the web and achieve full performance with the apps’ full set of capabilities - that they’d typically have when running native on Windows or Mac - in a web browser. The developers won’t actually have to write the WASM code directly either. Instead, they’d use WASM as a compilation target for programs written in other languages.

The main problem that WASM solves is the inability to use programming languages other than JavaScript on the web. Although JavaScript is a great programming language, it wasn’t designed to be super fast in large applications. What’s game changing about WASM is that it brings the performance of native applications, written in other programming languages, to the web in a way that's completely secure.

WASM should give significant speed increases in two main areas. First, it should significantly increase application start up speed. In fact, applications that are already using WASM have been able to cut application start up time in half, and as more optimizations are made, it will only continue to increase startup speed further. This will allow huge applications to load up very, very quickly. Secondly, WASM enables significant benefits in throughput too, which means that once code is compiled, it will run much faster - making applications more efficient and responsive which will significantly improve user experience.

WebAssembly has the following advantages:

• WASM is extremely fast, efficient and portable. Code can be executed at near-native speed across different platforms.
• WASM is also readable and debuggable. Although WebAssembly is a low-level language, it does have a human-readable text format that allows code to be written, viewed and debugged by hand.
• It’s also extremely secure as it’s run in a safe, sandboxed environment and like other web code, it will enforce the browsers same-origin and permissionless security policies.