Tectum FAQ

Tectum Blockchain is the world’s fastest decentralized blockchain that makes older networks like Bitcoin work faster and cheaper. It also offers various reward models for users and B2B Solutions to retailers and enterprises.

Blockchain is a decentralized, trustless digital environment regulated by the Consensus Protocol that maintains the integrity of the entire system and enables peer-to-peer interaction among its participants (nodes). It is a hard-defined balance between transparency and anonymity of every digital event (transaction). Consensus Protocol is the backbone of the network, as it governs how all the events are managed and issues are resolved. Therefore, the approval of multiple nodes is required in order to validate each event on the network. The communication between nodes is governed by Network Protocol because nodes are normally located distantly from each other, therefore the block data is subject to all kinds of slowing-down factors. Network Protocol establishes and maintains a connection between all the participants of the blockchain and is its most vulnerable component and bottleneck. The drawback of blockchain systems is their strong reliance on the network protocol. This limits how fast the entire network of nodes distributed throughout the world gets updated. The situation worsens if the Consensus Protocol policies overload the network with redundant data. It inevitably leads to congestion and high network fees.

Tectum employs proprietary Proof-of-Utility Consensus and superfast Network Protocols described in the Tectum Whitepaper. The Proof-of-Utility protocol optimizes data distribution, and the Network Protocol enables nodes to distribute and validate over 1 million digital events per second making Tectum a natural candidate to become an “Overlay Network” for blockchain-based payment systems like Bitcoin. Tectum boosts the circulation of native cryptocurrencies, eliminating transaction fees in the process using its frictionless payment system SoftNote.

Any blockchain is a decentralized software entity by definition and Tectum is no exception. There are various levels of decentralization that are available thanks to the genetic specifics of Tectum that make it highly scalable and modifiable.

Tectum is designed to operate in Public or Private modes (not at the same time) while offering Consensus as a Service. The mode of operation is defined by a Consensus protocol that governs the relationship and hierarchy among Nodes in the Cluster.

CaaS is an imbedded capacity of Tectum Software to design and implement the Consensus for every individual project on the go. Tectum Network is designed to operate in various privacy modes. This ranges from fully public blockchain mode governed by PoU to completely Private mode (JX Consensus).

Tectum is designed with “Consensus-as-a-Service” in mind, offering various settings from the ideal “public blockchain” to rigid enterprise settings designed for an individual to every project set of vulnerabilities.

A blockchain cluster is a number of Nodes united by a single consensus or an individual Blockchain environment. Tectum Clusters can be connected to each other through a selected Getaway Node, share Smart Contracts, DLLs, Tokens, etc.

Tectum is a blockchain of the latest generation that utilizes a combination of proprietary technologies like encryption algorithms, network protocol, consensus protocol (Proof-of-Utility) and network mapping to create a powerful and unique decentralized Framework capable of performing network updates with unprecedented velocities (Terminal Performance).

Setup is no different, different Consensus Smart Contracts are deployed on a system level for different setups. Fully Public Networks is governed by the Proof of Utility while private Networks use several different Consensus protocols tailored for each individual use case.

Absolutely yes. However, the final reward models need to be selected and approved first.

Tectum ran 51 million transactions across 8 different nodes. These transactions were completed in less than 15 seconds, bringing the average to just over 3.5 million transactions per second. This new record broke the previous record of 1.3 million transactions per second, thereby affirming Tectum as the fastest layer 1 blockchain in the world. Read more: TPS Test

Smart Contracts are processed by hardware and not a blockchain performance criterium, so the question is incorrect – Blockchain, just like any other system, is as fast as its slowest component. The slowest component in distributed software systems is naturally a Network protocol – a problem successfully solved by the Tectum team.

The Tectum network Cycle is a 3-phase event governed by the Topology. The Topology (Network Map) is created at the end of every cycle by the current Elect Node. There are 3 Base phases in every Network Cycle (Clock Cycle):

• READ: A newly elected pool of Master Nodes reads and collects all the transactions and passes them to the newly elected Elect Node according to the Network Map formed by the former Elect Node.
• STOP: All the events on the Tectum network except service events are suspended while the Elect Node is:
  1. Processing the transactions just received from Master Nodes.
  2. Forming Stack of Blocks
  3. Creating a new Network Map for the next network cycle.
• WRITE: The Elect Node submits the new Network Map and all the Blocks to the Master Nodes and resigns; Master Nodes update the rest of the Network.

Nodes do not have the freedom to recalculate their place in the network. Reconfiguration of the network map occurs several times per second by the current Elect Node during the STOP phase. At that moment, the network suspends processing all events due to internal reconfiguration status and only allows service events in. Until the next Cycle, all the transactions occur at static routes that are approved in the current Clock Cycle. After the READ (reading) stage, there is a WRITE (record) stage again and so, consequently, at 10-100 milliseconds frequencies for each stage.

No, the current Elect Node functions as a Mempool during the current network Cycle. It collects all the transactions during the READ Cycle from the Master Nodes.

Yes, the ratings of the nodes are stored in blocks and recorder in the entire history of blockchain. Nevertheless, the packet trajectories are formed randomly and are not predictable in advance. There is also a commutation among the nodes due to the logic of the “fat tree” topology (designed by Charles Eric Leiserson, MIT). This is where “higher” nodes (nodes closer to the root of the network’s “tree”) have more connections with other nodes than “lower” nodes. This process is maintained through atomic swaps. So, the answer to the second question is close to the answer to the first one. The routes are static for nodes at the agreed moment of time. In other words, we have two modes in the network:

1) servicing customer transactions, 2) updating and issuing a new map of routes.

The block size has a fixed length of 120 bytes that is independent of the “child” chains. For example, if a ”son” (“descendant”) of a “parent” has 8 “grandchildren,” then he controls them himself, sending his “father” (“ancestor”) only meta-information about the validity of “grandchildren”. “Grandchildren,” in their turn, control “great-grandchildren” and so on. Thus, “pseudo” (“false”) “sons” and “false grandchildren” simply would not be integrated into blocks of the neuro-chain due to lack of proof (“signatures”) from their “parents”.

Yes, we have clustering, and this was clearly stated in the whitepaper. Peer-to-peer nodes are joined into clusters, and their commutation is done by atomic swaps, which regulate the movement of more/less traffic. Clustering occurs if some part of the network falls off. Moreover, If there is a disconnection between some segment of the network and the main network, the segment would work separately from the main network as usual. Then the synchronization with the main network would occur after the connection is restored. As for the Ratings of nodes – the distribution of Ratings is done using a progressive scale of randomness. For example, a lower processing node and worse internet connection (smartphone) would have a better chance to leap 10 levels higher up the network “tree”. Meanwhile, a higher processing node (webserver with a wide channel that is closer to the top of the  “tree”) would go by only one level down. The higher the rating, the fewer accidents in the rating assignment. This rating itself depends on several parameters: 1) online time, 2) speed of data access, and 3) processor power. But as for the real network capabilities, there is something else that needs to be clarified, such as dependence on the number of smart contracts and transactions’ peculiarities. With regard to typology, our network is similar to the “Hierarchical Star” (a very scalable and productive model to this day), and it is possible to talk about the connections between nodes in this context. So those nodes are interchangeable and are connected by lateral links. The interchanging could be done up to the moment of network reconfiguration and deposition of unresponsive nodes into the “Inferno Set” of nodes that are not reliable and have a low probability of getting higher levels on the “Network Tree”.

Yes, the topology (map) of the network nodes is established prior to the transaction (READ) phase.

The Delphi version “Embarcadero Tokyo” is used. This version automatically compiles any code for the common Operating System (Windows, Unix, Android, Apple etc.).

All nodes are of the same type and are perceived as “full nodes”. Nevertheless, a node should be better deployed on a more productive device with a broadband Internet channel to work well within a neurochain. Nodes with higher processing speed (for example web-server in comparison to smartphone) enable higher productivity of their segments of networks (what is important at higher levels of “Fat Tree” in “Neurochain”) so they could be rewarded with a higher amount of internal cryptocurrency – not only for their time and random position but also for their productivity. To tell the truth a smartphone could hardly be used as a full node with high productivity and great reward.

3-tier architecture of the Tectum blockchain:

1. Upper Tier: Is the process of forming of Stack of Transactions: a) End-to-end numbering of the bundle of transactions received from a Pool of Master Nodes (the process of end-to-end numbering of the bundle of transactions, producing a sequence of hashes). b) Creation of Stack of Blocks using: 1 Tnx = 1 block principle (In RAM only). c) Producing the Hash of the last Block; d) Sending the entire Stack of Transactions following the Hash of the last Block back to the Pool of Master Nodes. In order to rid the Network of the burden of sending the entire Stack of Blocks;
2. Second Tier: Distributing the Stack of Transactions throughout the Network. The pool of Master Nodes repeats the procedure of the Elect Node sending the Stack of Transactions followed by the Hash of the last Block to the Network below. Every Node creates a Stack of Blocks from the Stack of Transactions and produces a Hash of the last Block. The Stack of Blocks is added to the Ledger only after the Hash of the last Block produced by each individual Node matches the one produced by Elect Node.
3. Third Tier: Decentralized Database: a) At least 7 server locations. b) Keeps client files, system files, public files, and intellectual property-related files.

Proof of Utility. Proof of Work and Proof of Stake models shift the responsibility for the Consensus to miners and reward them with Block rewards. Since Tectum does not use mining as a means to acquire a new Unit of Account, the events’ processing is trusted to a random Node using the “Lottery” principle. The proprietary True-Random Number Generator based on the Gaussian Distribution algorithm (https://www.investopedia.com/terms/n/normaldistribution.asp) gives it a chance to become a Master Node. Given that the Node’s rating qualifies it to participate in the “Lottery” – every Node has a fair chance to become a Master Node. Elected Master Nodes form a pool of multiple Nodes that run yet another voting algorithm among themselves called “Game” (see Game Theory) in order to elect an “Elect Node” at rates reaching 5 times per second. The new Elect Node creates a Chain of Blocks comprised of all the Events gathered by all the Master Nodes to create a Block Line Count and sends it back down the Network. The transmission starts with the Master Nodes’ pool, which forwards it down to the rest of the network. Delegate and Nominal Nodes are the ones that actually write Blocks and form Blockchain as is seen by the Network Users in the Explorer. Every Node is designed to service Smart Contracts, producing Blocks. The following Types of Nodes occur on the tectum network:

1. Elect Node: Elected from the Pool of Master Nodes during the Game. It is no different from any other Node, except that it is responsible for the end-to-end numbering of the bundle of transactions submitted to it.
2. Master Node: The minimal number of Master Nodes is 2 and is proportional to the number of Delegates.
3. Delegate Node: A Node that has earned the rating (Weight of Chance) high enough to participate in the “Game” to become a Master Node.
4. Nominal Node: A Node that does not have enough rating to participate in the Game to become a Master Node.

Example: Master Nodes collect following Events: Master Node 081 collected 5 Events, Master Node 022 collected 12 Events, Master Node 007collected 8 Events – 25 Events in total – Block Line Count.

OUR UNDERSTANDING IS THAT AS PROOF OF UTILITY IS A NEW CONCEPT, PLEASE POINT TO ANOTHER NETWORK THAT USES SOMETHING SIMILAR.

Proof of Utility is using an algorithm similar to the one used by Paxos. Please see: https://en.wikipedia.org/wiki/Paxos_(computer_science)

1 transaction = 1 Block = 1 Elect Node = 1 Pool of Master Nodes. Therefore, it is impossible to confirm the spending of the same balance (same amount) twice since the next transaction is going to have the same hash. In addition, an Elect Node is not allowed to process more than 1 transaction generated by the same address.

The transaction is signed by the private key and verified using Public Keys on every Tier Phase).

Yes, the Rating algorithm. While there is no penalty, the Node rating drops.

In the Decentralized Storage such as Linux file archiving servers; files can be kept encrypted or not; hashes of the files are kept in Blockchain in a 32B format

Impossible scenario, the chance of losing the access to the data kept on 7 locations equals to: (1/100) * (1/100) * (1/100) * (1/100) * (1/100) * (1/100) * (1/100).

Yes, for the ledger, but the actual data is kept in Decentralized storage or clients’ computers.

Local Explorer means the search engine that has access to a particular chain ledger. For example, the SoftNote Explorer is designed to search through the chain of blocks that are responsible for recording of previous passcode of all SoftNote Bills.

Every Chain of Blocks is tailored to carry the information individually to the product; TET includes the balances, while SoftNote does not.

Tectum Decentralized Storage is an added layer service that targets Logistical, Intellectual Property, and other sensitive data-related operations. Some partners are not willing or simply cannot safely store their data. The seamless integration with the native Blockchain layer is a major winning factor when a large amount of documentation must be instantly accessible to all transacting parties. Tectum Decentralized Storage is a Smart Contract: The file hash signature + File location address is written to the Decentralized Storage chain. The file itself is stored in multiple server locations not related to each other. The access is public; the file can optionally be encrypted.

SC executes a new Chain of Blocks specific to Events with an identical algorithm to process the identical Block Format (Block Properties). Tectum SCs are designed to function through UI for an average user, and the UI is normally a Desktop application.

No, DLL operates as SDK for the Nodes’ software. But we can accept data from Dynamic Link Library; DLL can be written in any language of the developer’s choice.

On the Tectum Network, the Elect Node runs all Smart Contracts. Every SC is a Chain in itself with its own Chain of Blocks and multi-tier structure that includes Hash Drive, Hash Stacking, and DB management.

Smart Contracts are located in the binary file of an executing Node in the local DLL folder. DLL is designed to run on active Elect Node only. Furthermore, the DLL is updated prior to every SC execution update occurring.

The Smart Contract in question is hashed and the hash is placed in the particular Block. The DLL is automatically loaded (updated) from the Decentralized Storage or another recourse (depending on the Model of this particular tectum Cluster) by the Elect Node after the Hash of this Smart Contract is found. The DLL files are updated if required, and the updated version of the Smart Contract is executed to enable cross-platform implementation. Therefore, every SC executing Node must run the following cycle in order to execute the SC: Find Hash of the SC > Find DLL > Find SC in the DLL file > update the SC in own DLL > Execute the SC.

After downloading the Ledger files, the Node checks hashes along the chain from 0 to the Number of the searched Block. During transaction, every node checks every new block before executing WRITE function.

Yes, each node has a 100% synchronized, full copy of the Ledger + Last Block validation check written on HD. All operations are performed in memory, the result is two. 1) A chain of new blocks is kept in memory. 2) The hash of the last block. If the check is successful, the hash blocks are written to the Ledger.

Command: check node hash

No, Hash of Last Block only. The actual search is done by our proprietary NoSQL Search Engine.

Tectum does not connect to other blockchains. In the case of Bitcoin, the transactions are executed as Tectum Smart Contracts; Tectum holds the BTC and runs a ledger of the transactions on the Tectum blockchain. In addition, Тectum signs BTC transactions and saves them in the ledger. Therefore, Tectum can guarantee BTC transactions via its own Ledger.

wBTC is an ERC20 Token, where you buy the Token for real BTC – In our system, you transfer real BTCs to the BTC Wallet on Tectum. In case the Ethereum Network crashes, the holder of wBTC loses everything. This is not the same in ours because the Wallet holder gets to keep his BTCs in the BTC Wallet, and they are recoverable from the Bitcoin Network using a conventional Bitcoin private key.

You can import Your Bitcoin (Native network) private key if Tectum is unable to manage your BTC address (should such occurrence take place) into any conventional Bitcoin Wallet.

That would be the scenario of all the datacenters and Nodes – the Company’s and the clients – simultaneously shutting down without the chance of restoring data, all our backups destroyed and all our Sysadmins murdered all at the same time.

Tectum does not use BTC; Tectum signs BTC transactions only through BTC node control. Tectum hashes the hash of the BTC transaction and writes it to Tectum ledger.

Cybersecurity is defined by the encryption algorithm and overall redundancy of the system. The encryption level of Tectum is same as Bitcoin network, the level of Redundancy is defined by the client and not us.