Tectum Blockchain 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 trust-less digital environment regulated by Consensus Protocol which maintains the integrity of the entire system enabling peer-to-peer interaction among its participants (nodes) as well as 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 components and bottleneck. The drawback of blockchain systems is their strong reliance on the network protocol which 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. This inevitably leads to congestions and high network fees. 

Tectum employs proprietary Proof-of-Utility Consensus and super-fast Network Protocols described in Tectum White Paper. 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 both (not at the same time) offering Consensus as Service; The mode of operation is defined by a Consensus protocol that governs the relationship and hierarchy among Nodes in the Cluster.

CaS 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: from fully public blockchain mode governed by PoU to completely Private mode (JX Consensus).

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

Cluster is a number of Nodes united by a single consensus, an individual Blockchain environment; Tectum Clusters can be connected between 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).

The Terminal Performance of Tectum has been flatulating between 700,000 and 1,380,000 transactions per peak-second in 3-continent test conditions in cross-writing & reading modes: https://tectum.io/videos/.

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.

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 of recalculating 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 this moment the network suspends processing all events due to internal reconfiguration status only allowing service events in. Then, until the next Cycle, all the transactions occur et static routes that are approved in the current Clock Cycle. After 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. And there is commutation among the nodes due to the logic of “fat tree” topology (designed by Charles Eric Leiserson, MIT) 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.

Yes, we have clustering, this was clearly stated in White Paper. 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 misconnection between some segment of the network and the main network the segment would work separately from the main network as usual, and 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” than a higher processing node (webserver with a wide channel that is closer to the top of “tree”) would go by only one level down. The higher the rating, the fewer accidents in ratings assignment. And the rating itself depends on several parameters: 1) online time, 2) speed of data access, 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 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 that are connected by lateral links. And 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 low probability to get 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.).

The block size has a fixed length of 120 bytes 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 metainformation 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 neurochain due to lack of proof (“signatures”) from their “parents”.

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 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 followed 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. Pool of Master Nodes repeats the procedure of the Elect Node sending the Stack of Transactions followed the Hash of the last Block to the Network below – every Node creates a Stack of Blocks from Stack of Transactions and produces 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 one produced by Elect Node.
  3. Third Tier: Decentralized Database: a) At least 7 server locations; b) Keeps client files; system files, public files, intellectual property related files.

Proof of Utility. Proof of Work and Proof of Stake models shift the responsibility for the Consensus on miners, rewarding them with Block rewards. Since Tectum does not have Mining as a mean 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) giving it a chance to become a Master Node. Given the Node’s rating qualifies it to participate in the “Lottery” – any such 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. Elect Node creates a Chain of Blocks comprised of all the Events gathered by all the Master Nodes and forms a Block Line Count and sends it back down the Network starting with Master Nodes’ pool which forwards it down to the rest of the network. Delegate and Nominal Nodes are ones that actually write Blocks and form Blockchain as it 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 for any other Node except Elect Node 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 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 because 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, there no penalty, just the Node rating drop.

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 individual to the product; TET includes the balances while the SoftNote Chain does not.

Tectum Decentralized Storage is an added layer service, targets Logistical, Intellectual Property and other sensitive data related operations; some partners are not willing or simply do not have the capacity to 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 SC are designed to function through UI for an average user; 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 Tectum Network, all Smart Contracts are run by the Elect Node. Every SC is a Chain in itself with its own Chain of Blocks and multi-tier structure that includes HashDrive, 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; DLL is updated prior to every SC execution should those updates occur.

The Smart Contract in question is hashed, 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, then the DLL files is updated if required and the updated version of the Smart Contract is executed; cross-platform implementation is possible. 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 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, plus Тectum signs BTC transactions and saves them in the ledger therefore, Tectum can guarantee BTC transaction 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 when Ethereum Network crashes the holder of wBTC loses everything, in our case not, because the Wallet holder gets to keep his BTCs in BTC Wallet recoverable from Bitcoin Network using 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.

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.