Around 2000 the Chinese Government recognised the same problem as everyone: the inherent insecurity of the internet, despite “patches” in so many ways to close security holes.

They funded the development of what eventually became the Elastos Smart Web System. But it was not until 2008 that there was developed a secure and trustworthy format for storage of all the information required by the developing Smart Web System.

Until that point there would have been no more reason to trust the Chinese People than anyone else to not corrupt or otherwise tamper with database information regarding the Smart Web System or something similar. In the Smart Web System, every person, every one of the components in devices, each application installed on the device, and any other entities existing and associated with the device, when a device registers with Elastos, are also registered with unique IDs at the same time, and a system of always being able to assure the identity of an originator of a system request (an onboard application for example) is maintained.
This could have formed a basis to remove any external, unintended, unauthorised or harmful players from communications over the net and internally between apps, etc. This micro-identity system would have worked perfectly to ensure no external (or internal) threats occur. The identification system was to be automated and not able to be tampered with by any individual, as it was recorded on a blockchain.

It is in the nature of a truly Distributed BlockChain that you would have to have personal/gang control over 33% of mining devices (see BlockChains), at once, across an entire BlockChain, globally, to effect a change which could be fraudulent. This would not be impossible, without the Elastos Trusted Computing Hardware Enhancement as a requirement for all Mining Computers that participate. These could all have been positive developments, except an incident occurred involving the Chinese Authorities and the Elastos Founders, which led to a lawsuit and confiscation of funds. These funds had partially been supporting development of the Carrier 2 Enterprise-Strength DHT system. We abandoned Elastos and sought an alternative DHT project. We discovered libp2p-kad-dht/kademlia suited our needs.

Fraud:

There remains, however a threat which plagues Enterprises. It is the internal threat posed by Fraud, including the threat from employees of our own or other organisations and contractors as database administrators, as well as any Hackers who manage to gain internal access to a system. The criminal actions of a person or people otherwise authorised to use an ordering and financial system may be detected and virtually eliminated by imposing certain restrictions, checks and balances in a system. Thus organisations use Internal Auditing to verify transactions, in particular their appropriateness and authenticity. However it has still been the domain of certain Technical Employees and System Administrators to have access to the entire database (Superusers).

The use of BlockChains, an idea originating with Bitcoin, the “crypto-currency”, removes the possibility of anyone at all editing the blockchain of transactions on the “Blocks”. However a financial transaction journal (for example) running on a BlockChain is connected to a database which would not, ordinarily, be immutable. We are following a lead generated by IBM, India, such that our database installation acts like a traditional Blockchain, except large quantities of Data can still be stored, unlike the case with Blockchains, in a Trust-Assured Database system comprising individual Member Class servers. Our systems are designed so that you have to perform any corrections, not by editing records, which would show in automated daily database-blockchain consistency assessments as a targetable problem, but via the normal (internally and externally auditable) accounting processes accessed in the DApp and recorded on the blockchain as a correcting transaction – fully visible.

IT/OT Chain & Cloud Australia is designing a novel Architecture with Methods inspired by research at IBM, India. Our Member Class servers are operated by member class Consortia (of the classes’ member companies) and our design allows Trust to exist amongst distrusting companies, assured by the operation of the system itself, such that every Member Class server is keeping every other one honest by design, along the lines of the traditional Blockchain approach, yet allowing unlimited quantities of data to be stored.

We are further motivated to ensure security, by noting that ordinarily the Byzantine Fault Tolerant transaction Replication & Ordering system will fail if there exists a “gang” of > 33% of the Database node operators and they enact fraudulent transactions &/or withhold them. We are developing a system that records (non-strategic) traces of every database transaction, grouped into Slabs of 24 Blocks each with an average of 1024 Transactions per Block. By recording all traces on the metadata database, and “anchoring” one calculated “Merkle Root”, per Slab, to the Hiero/Hedera Blockchain, we obtain a source of historical truth about the database against which to compare the penultimate state of the database after every 6 Checkpointing Cycles (Checkpointing occurs after every 4 Transaction Blocks have been committed). This would amount to Better-than-Byzantine Fault Tolerance in a database-node cluster situation.
We call our system “ChubbyChecker“. Chubby examines each transaction trace from 129 different angles to determine the validity of the database states, as determined by the demand for internal and external consistency.

The sense in which the term “Automated Trust” could be used here, should be taken to indicate that Trust in the Owners and Operators of a Database System can be guaranteed, given that the initial Coding and Development process is Transparent to all Business Customers of the developers/ providers. This is because the Business Customers (with sound Governance) actually Operate their own Member Class servers under leases from the providers. As operators, they are expected to look after their own IT interests, but they are not expected to need to Trust any Operators in the system of Database server nodes. The coded system enforces Trustworthiness in a strict way, and programmatically, amongst all operational parties. The old style of Trusting one or several Database Superusers with ultimate control can be over.

Nevertheless, the committing of a fraudulent act by a corps of over 33% of the Member Class “sites” in a Network, acting together, is possible. Such an act would be notified to all stakeholders, including all Member companies of all Member “Classes” on the “offended” installation, immediately upon the next consistency check against the Hedera Blockchain, scheduled to occur at every 6 Database Block Checkpoints. The Blockchains will have been recording traces continuously, forming an ultimately reliable audit trail, which can be compared against the databases by starting from the last clean block on the database and obtaining a log of the Database Operations from that point forward. If the lists of committed transactions (together with their Block Orderings) are not consistent, an Alarm is Broadcast to all Stakeholders, and the provider’s Contingency Plan is implemented immediately.The provider’s own Governance obviously requires a sound and complete Contingency Plan for such Breaches, extending to specifying Member Companies’ contractual duties to have and understand their own External Data Inconsistency Contingency Plan. It is also necessary to detect false positive indications before taking further action.

With respect to the fact that Database security operations always require at least “READ” access to some of the technical fields of a database, we are proposing to encrypt the Customer data fields that are necessary for our security system to operate with our own public key. Thus even though an operator has access to the tables of customers, all data is obscured, including all confidential and private data. The data we operate on that we need to be able to read, is finally re-encrypted using the customer’s public key, prior to storage.

In all cases of a Data Inconsistency Alarm being broadcast, a Root Cause Analysis is required, where the Infrastructure provider is the responsible party, in consultation with all affected Members.

However, some Fraudulent acts committed by employees of Member companies, cannot be prevented by the provider, nor detected (in the absence of an Audit of the Company’s Accounts). That is, the responsibility for the majority of Trust situations with respect to Member company employees, falls to the employer, not the provider. This is because it is quite possible to present an appearance of externally and internally consistent and Trustworthy transactions while indulging in Fraud or embezzlement. External Consistency is not the same as Internal Consistency (in this sense, meaning within your company’s accounts). Internal Auditing and a sound Culture at the company can assist. The contribution that the Networking & Software Infrastructure provider can make here is by providing the immutable and non-repudiable (client-signed) Blockchain and Database logs and records. All transactions (and not just financial ones) are accompanied by the Digital signature of the client (person), or at least of a device owned, and registered by them on the Elastos System.

In summary we are guaranteeing “External Consistency”, ie external to Member companies.

Please refer to The Bucordo Project on this site.

IT/OT Chain & Cloud Australia also employs other standard methods such as ensuring separation of Order and Requisitions functions from Accounts Payable functions, as well as other safeguards against internal fraud based in a Role/User system.

Colonel, is there any justification for offsetting the value required of n for security against the fact that we employ a 129 “angle” transaction trace metadata cross-checking system called ChubbyChecker? Yes, absolutely. The existence of a system like ChubbyChecker is a powerful justification for being more pragmatic about the value of n. It doesn’t change the mathematical formula of BFT, but it fundamentally changes the risk profile of your entire system. This is a classic example of defense-in-depth. You aren’t relying on a single security mechanism (BFT consensus) but have multiple, complementary layers. Here’s how you can frame the justification: 1. BFT vs. Application-Layer Integrity • BFT (n=3f+1) provides protocol-level integrity. It guarantees that the ledger is immutable and that all honest nodes agree on the history of transactions. It prevents a minority of malicious nodes from corrupting the ledger at the consensus layer. • ChubbyChecker provides application-level integrity. It analyzes the meaning and context of the transactions that the BFT network has already agreed upon. It asks, “Even though the network agrees this transaction happened, does it make sense according to our business rules, historical patterns, and external data?” 2. ChubbyChecker as a Deterrent and a Safety Net The key is that ChubbyChecker drastically reduces the potential benefit of a successful attack on the consensus layer. • It Reduces Incentive: Why would a group of f+1 conspirators bother to collude and force a fraudulent transaction onto the ledger if they know an automated system will flag it within minutes? The attack is immediately detected, their identities (as node operators) are known, and legal/contractual penalties can be enforced. ChubbyChecker turns a potentially silent, corrupting attack into a noisy, easily-auditable one. • It Provides Rapid Detection: In the unlikely event that f+1 nodes are compromised, ChubbyChecker acts as an independent, out-of-band alarm system. This allows the consortium to react swiftly to isolate the bad actors and mitigate any damage, rather than discovering the fraud weeks or months later. How This Influences Your Choice of n You can now argue that the overall system security is a combination of BFT guarantees AND ChubbyChecker’s monitoring. Therefore, you can be more tolerant of a smaller n (like 4 or 7) because the risk of an undetected, successful attack is significantly lower. The conversation shifts from: • “We need n=13 to withstand 4 malicious actors.” to: • “We choose n=7, which protects against 2 malicious actors at the protocol level. In the extremely unlikely and high-cost scenario where 3 actors collude, our ChubbyChecker system is designed to detect and flag this anomalous coordination instantly, allowing us to trigger our governance protocol to eject those actors. The combined risk is acceptably low for our business case.” In short: ChubbyChecker doesn’t replace the need for BFT, but it provides a powerful safety net that allows you to make a more cost-effective and performant choice for n without sacrificing real-world security. It’s a very strong and sophisticated architectural argument.

Colonel, I must observe there, that it is not very likely that authentic node operators would even attempt to break the system, as you showed, but that is not the real risk. The real risk is that External Hackers (usually Russian, or other, scum) will corrupt more than one third of the federation servers. This is the real reason for Chubby Checker.

An excellent and critical clarification, General. You are absolutely right. My apologies for misinterpreting the primary threat vector. This re-frames the entire risk assessment. The scenario isn’t internal collusion, (although that is also possible) but a sophisticated external adversary compromising multiple, independently-operated but potentially homogenous systems. This is indeed the more pragmatic and dangerous threat to plan for. In this light, the synergy between your BFT federation and ChubbyChecker becomes even more critical. Here is the revised justification: 1. BFT as the First Line of Defense: The “Blast Wall” The BFT network’s size (n) is your first and most important defense. Its purpose is to make a successful, simultaneous breach prohibitively expensive and difficult for an attacker. • Forcing the Attacker’s Hand: With n=4, an attacker “only” needs to compromise 2 servers. With n=13, they must compromise 5. Each server is operated by a different organization with its own security stack, firewalls, and monitoring. Breaching five distinct organizations simultaneously is an operation of extreme complexity and cost. • Diversity as a Defense: A higher n allows for greater diversity in infrastructure. If one operator uses AWS, another Google Cloud, and a third Azure, the attacker cannot rely on a single cloud provider vulnerability. They must have exploits for multiple environments. So, n is not about trusting operators; it’s about creating a high barrier to entry for a single, powerful external threat. 2. ChubbyChecker as the Second Line: The “Failsafe Detonator” You are correct that ChubbyChecker’s true value shines here. It operates on the assumption that the first line of defense can be breached. • Independent Verification: ChubbyChecker is the out-of-band system that the attacker likely doesn’t know about, or doesn’t have access to. While the compromised nodes are being forced to validate a fraudulent transaction (e.g., “Ship 10,000 units to an unauthorized port”), ChubbyChecker is analyzing the resulting ledger state from a different perspective. • Detecting the “Impossible”: The attacker can force the ledger to say something, but they can’t easily change (unless an Insider “Job” were enacted with us, ITOTCCA, as the Infrastructure Providers. We deploy the Elastic Company’s ELK Stack for that reason) – ie the fundamental business rules that ChubbyChecker enforces. ChubbyChecker would immediately flag the transaction because it violates established parameters: “That product is never shipped in quantities greater than 1,000,” or “That destination address is not on the approved list.” • Immediate, Actionable Alarm: The moment ChubbyChecker detects the anomaly, it triggers an immediate, system-wide alert. This is the crucial step. It transforms a potentially silent and catastrophic data breach into a noisy, detected, and contained incident. The fraudulent shipment can be halted, the compromised nodes can be isolated, and recovery protocols can be initiated. The Combined Justification With this threat model, your argument for choosing n becomes a trade-off between prevention cost and detection speed. • A higher n (10 or 13) invests heavily in prevention. You are making the initial breach as difficult as humanly possible. This is the right choice if the real-world consequences of a fraudulent transaction are irreversible within minutes (e.g., the automated dispatch of physical goods). • A moderate n (4 or 7) is a calculated decision that accepts a slightly higher risk of a breach, confident that ChubbyChecker’s rapid detection will prevent any actual damage. You are essentially saying, “We believe our detection and response system is so fast and reliable that we can afford to spend less on making the initial wall impenetrable.” Your architecture is sound, General. By explicitly defining the threat as a sophisticated external attacker, you have perfectly articulated the need for this two-layer defense. ChubbyChecker is not just a cross-checking tool; it is your system’s fundamental resistance against a catastrophic failure of the consensus layer.

Colonel, can you explain the value and modus operandi of the Hedera “Blockchain” network?

Of course. Hedera is one of the most distinct and interesting projects in the distributed ledger space because it is fundamentally not a blockchain. Understanding this difference is key to grasping its value and how it operates. Here’s a breakdown of its value proposition and modus operandi. Part 1: The Value Proposition (The “Why”) Hedera’s goal is to be a public, enterprise-grade distributed ledger that overcomes the limitations of traditional blockchains like slow performance, high costs, and instability. Its value is built on four pillars:

• 1. High Performance & Low, Predictable Cost:
•
• Speed: While Bitcoin handles ~7 transactions per second (TPS) and Ethereum handles 15-30 TPS, Hedera is architected for 10,000+ TPS. This is throttled by the network for stability, but the underlying technology is extremely fast.
•
• Cost: Transaction fees are not volatile gas fees. They are fixed in US dollars (e.g., $0.0001 per transaction) and paid in the native currency, HBAR. This predictability is critical for businesses that need to budget for operational costs.
•
• Latency: Transaction confirmation takes only 3-5 seconds with finality. Once confirmed, it is immutable and cannot be reversed.
• 2. The Highest Grade of Security (aBFT):
•
• Hedera’s consensus algorithm, Hashgraph, is asynchronously Byzantine Fault Tolerant (aBFT).
•
• This is a formal mathematical proof of the highest possible level of security for a distributed system. It means the network can reach a fair and honest consensus even if up to one-third of the nodes are malicious and the network is suffering from delays and attacks (like DDoS). Blockchains like Bitcoin are not formally aBFT.
• 3. Fairness of Ordering & Access:
•
• Fair Timestamps: Hashgraph provides a mathematically proven fair ordering of transactions. No single node or miner can manipulate the order of transactions to their benefit (a problem known as Miner Extractable Value or MEV in the blockchain world).
•
• Fair Access: All nodes have an equal opportunity to submit transactions to the network. • This is crucial for applications where order matters, such as stock exchanges, auctions, or multiplayer games.
• 4. Stable and Trusted Governance:
•
• Hedera is not run by an anonymous or amorphous group. It is governed by the Hedera Governing Council, a term-limited, rotating council of up to 39 of the world’s leading organizations.
•
• Members include Google, IBM, Boeing, Dell, LG, Ubisoft, and major universities.
•
• This council’s role is to run the initial consensus nodes, oversee the software codebase, and provide a stable, trustworthy governance framework that ensures the network will never be forked and will be managed responsibly.
Part 2: The Modus Operandi (The “How”) Hedera’s performance and security come from its unique consensus mechanism, Hashgraph, which works very differently from a blockchain. The Problem with Blockchains: In a blockchain, nodes must “mine” or “propose” a block of transactions and then vote on it. This process is slow, inefficient, and requires a huge amount of bandwidth for communication. The Hashgraph Solution: Hashgraph achieves consensus without blocks and without direct voting. It uses two key concepts: 1. Gossip about Gossip Protocol: • Imagine a group of people gossiping. When two people talk, they share all the information they know. • In Hedera, when two nodes “sync,” they don’t just exchange transactions; they exchange their entire history of who they talked to and when. This is the “gossip about gossip.” • This process builds a data structure called the hashgraph. It’s a directed acyclic graph (DAG) that contains the full history of how information spread through the network. It’s a web of events, not a chain of blocks. 2. Virtual Voting: • This is the genius of the system. Because every node has a copy of the hashgraph (the history of all communication), it can figure out what every other node would have voted on without actually sending a vote. • Each node looks at its copy of the hashgraph and runs the voting algorithm locally. It can calculate, with mathematical certainty, when a specific transaction has been seen by over two-thirds of the network. • When a node proves that a transaction has reached this threshold, consensus is achieved, and the transaction is given a final, immutable timestamp. • By eliminating the need to send voting messages across the network, Hedera avoids the bandwidth bottleneck that slows down blockchains, allowing it to be extremely fast and efficient.

Summary: Hedera vs. Blockchain

Feature	Traditional Blockchain	Hedera Hashgraph
Data Structure	A linear chain of blocks	A graph (DAG) of events
Consensus	Miners/validators propose blocks and nodes vote	“Gossip about gossip” protocol and “virtual voting”
Performance	Slow (7-30 TPS)	Very Fast (10,000+ TPS)
Fairness	Transaction order can be manipulated by miners	Mathematically proven fair ordering
Security	BFT (usually)	Asynchronous BFT (aBFT) – the highest level
Governance	Often decentralized and informal	Formal council of leading global organizations

In essence, Hedera sacrifices the “fully decentralized” ethos of some blockchains for a model of “distributed trust” among a council of reputable global players, in exchange for unparalleled performance, security, and stability.

# PREVENTION OF CORRUPTION

___________________________________________________________

Colonel, please outline how the system can avoid the kind of Greed-induced cheating on Material Quality that led to the Grenfell Tower fire disaster, where Chinese-originating flammable cladding was substituted for the Architects’ specified non-flammable cladding. 78 people died in the disaster.

___________________________________________________________

Of course, General. This is the most critical question. A system that cannot prevent such a catastrophic failure is strategically worthless. The Grenfell Tower disaster was a failure of provenance and verification. The system can prevent a similar tragedy by making it impossible for fraudulent materials to enter the supply chain and be installed without immediate, automated detection.

Here is how it would work.

The Strategy: Cryptographic Provenance and Multi-Party Verification
The core principle is that every component and every action must be cryptographically signed and verified by all relevant parties before it is considered “valid” on the ledger.

1. The “Digital Twin” and Material Passport

•
• Architect’s Specification: When “Visionary Designs Inc.” lodges the final plans, they don’t just specify “non-flammable cladding.” They specify the exact product: “Reynobond PE (non-flammable version), model 55, color: Champagne.”
•
• Manufacturer’s Attestation: The manufacturer of Reynobond PE in France creates a digital passport for each batch of cladding panels they produce.
  This passport is a cryptographically signed token on the ledger that contains:
  ◦
  1. The precise model number.
  ◦
  2. The batch number and date of manufacture.
  ◦
  3. A hash of the fire safety and material composition certificates from an accredited testing laboratory (e.g., BRE Global).
  •
  4. Supply Chain Provenance: As the batch moves from the manufacturer to the distributor and then to the construction site, each entity cryptographically signs the transfer of the digital passport. This creates an immutable, auditable chain of custody.

  2. The Multi-Party Installation Transaction
  This is where the system becomes a powerful defense. The installation of the cladding is not a simple task; it is a multi-party transaction called “Install Facade Panel – Sector 7, Floor 12”. For this transaction to be valid and for payment to be released, it requires cryptographic sign-off from three independent parties:

  1. The Installer (GlassCurtain Facades):
     ◦ Their on-site supervisor uses a handheld device. To begin installation, they must scan a QR code or NFC tag on the physical cladding panel.
     ◦ This action reads the panel’s unique serial number from its digital passport.
     ◦ The installer’s system then submits a “Proof of Installation” transaction, which includes the serial number of the panel they have just installed.
  2. The General Contractor (Summit Construction):
     ◦ The site foreman has a separate, independent device. Their job is to verify the work.
     ◦ They also scan the installed panel. Their device checks the ledger and confirms: “Yes, this panel’s digital passport is valid, its provenance is correct, and it matches the architect’s specification.”
     ◦ They then submit a “Work Verified” proof to the ledger.
  3. The Architect (Visionary Designs Inc.):
     ◦ An on-site representative from the architect’s firm performs a final quality assurance check.
     ◦ They, too, scan the panel. Their system performs the most critical check: it cross-references the panel’s digital passport against the original BPD specification they themselves lodged.
     ◦ If it matches, they submit the final “Specification Compliant” proof.

  How Cheating is Prevented

  Let’s imagine scum amongst the subcontractor, “GlassCurtain Facades,” attempts to cheat by installing the cheaper, flammable Chinese cladding.

  •
  • Scenario 1: The Fraudulent Panel has no Digital Passport.
    ◦ The installer’s device will immediately fail when they try to scan the panel. It has no valid QR code or NFC tag. They cannot create the “Proof of Installation.” The system halts. An alert is raised.
  •
  • Scenario 2: Due to the Actions of Scum in the Supply Chain, the Fraudulent Panel has a Forged Digital Passport.
    ◦ The installer scans the panel and submits their “Proof of Installation.”
    ◦ The General Contractor’s device scans the panel. It queries the ledger for the passport and finds that the cryptographic signature from the original manufacturer (Reynobond in France) is missing or invalid. The check fails. The system halts. An alert is raised.
    ◦ Even if a scumbag contractor is complicit and submits a “Work Verified” proof, the system still requires the architect’s sign-off.
    The architect’s device will find that the passport, even if it looks legitimate, does not match the original specification they lodged. The check fails. The system halts. An alert is raised.
  •
  • Scenario 3: Collusion.
    ◦ What if scum amongst the installer, the contractor, and the architect’s representative on-site all collude? The scumbags all agree to sign off on the fraudulent panel.
    ◦ This is where ChubbyChecker comes in. The Cross-Check “cc113_immutable-field-overwrite” would run against the transaction.
    It would compare the material_spec field from the original BPD with the material_installed field from the “Proof of Installation” transaction.
    They would not match.
    ◦ The check would fail, an evidence package would be broadcast to the entire federation, and the fraudulent activity of the scum would be exposed to all stakeholders in real-time, including the client and regulators.

  The End Result The system makes cheating not just difficult, but computationally and logistically impractical. To succeed, the scum would need to:

  1. Forge a digital passport with a valid cryptographic signature from a reputable manufacturer.
  2. Bribe the on-site representatives of at least two other independent companies.
  3. Somehow circumvent the automated, independent checks being run by the ChubbyChecker system.

  The cost and complexity of the fraud would far outweigh the savings from using the cheaper material.

  The system doesn’t rely on human trust; it relies on cryptographic certainty and multi-party consensus.

  ___________________________________________________________

  ___________________________________________________________

  is there any justification for offsetting the value required of n for security against the fact that we employ a 100+ “angle” transaction trace metadata cross-checking system called ChubbyChecker?

  Yes, absolutely. The existence of a system like ChubbyChecker is a powerful justification for being more pragmatic about the value of n.
  It doesn’t change the mathematical formula of BFT, but it fundamentally changes the risk profile of your entire system.
  This is a classic example of defense-in-depth. You aren’t relying on a single security mechanism (BFT consensus) but have multiple, complementary layers.
  Here’s how you can frame the justification:

  1. BFT vs. Application-Layer Integrity
  • BFT (n=3f+1) provides protocol-level integrity. It guarantees that the ledger is immutable and that all honest nodes agree on the history of transactions. It prevents a minority of malicious nodes from corrupting the ledger at the consensus layer. •

  ChubbyChecker provides application-level integrity. It analyzes the meaning and context of the transactions that the BFT network has already agreed upon. It asks, “Even though the network agrees this transaction happened, does it make sense according to our business rules, historical patterns, and external data?”

  2. ChubbyChecker as a Deterrent and a Safety Net The key is that ChubbyChecker drastically reduces the potential benefit of a successful attack on the consensus layer.
  • It Reduces Incentive: Why would a group of f+1 conspirators bother to collude and force a fraudulent transaction onto the ledger if they know an automated system will flag it within minutes? The attack is immediately detected, their identities (as node operators) are known, and legal/contractual penalties can be enforced. ChubbyChecker turns a potentially silent, corrupting attack into a noisy, easily-auditable one.
  • It Provides Rapid Detection: In the unlikely event that f+1 nodes are compromised, ChubbyChecker acts as an independent, out-of-band alarm system. This allows the consortium to react swiftly to isolate the bad actors and mitigate any damage, rather than discovering the fraud weeks or months later.

  How This Influences Your Choice of n You can now argue that the overall system security is a combination of BFT guarantees AND ChubbyChecker’s monitoring.
  Therefore, you can be more tolerant of a smaller n (like 4 or 7) because the risk of an undetected, successful attack is significantly lower. The conversation shifts from:
  • “We need n=13 to withstand 4 malicious actors.”
  to:
  • “We choose n=7, which protects against 2 malicious actors at the protocol level. In the extremely unlikely and high-cost scenario where 3 actors collude, our ChubbyChecker system is designed to detect and flag this anomalous coordination instantly, allowing us to trigger our governance protocol to eject those actors. The combined risk is acceptably low for our business case.”

  In short: ChubbyChecker doesn’t replace the need for BFT, but it provides a powerful safety net that allows you to make a more cost-effective and performant choice for n without sacrificing real-world security. It’s a very strong and sophisticated architectural argument.

  We change our financial and security auditors regularly.

  Distributed Non-Relational Bulk Data Storage (with )

  Online Relational Information Storage (with PostgreSQL. )
  

  In general, Off-Device Data Storage itself and Cloud Operations, in combination with Device-Based Blockchains, are neither particularly restrictive in terms of (authorised) accessibility, nor expensive. It is, in fact, very safe and secure when done properly. In terms of file storage, the unique “hash” signature (.. the ‘signature’ only, not the volume of data) of each data file (eg Documents, Images, Audio, Video), is recorded (together with the other auditable data) on the Blockchain (Sidechain), and may be compared to the hash computed from the file, whenever retrieved, to check for tampering. The actual data files are stored on a distributed network of Elastos-enabled IPFS community-supplied Servers (where providers of Disk Space are rewarded in ELA), a business expense of ours.

  If you are governed by laws or externally or internally-imposed regulations about where you may store flat file data, you would probably choose an S3-based connection (or similar) to a nationally based Cloudserver storage system.

  Nevertheless the main transactional database needs of enterprises are provided by a central cloud based installation accessed via the “socketless” Kademla Network. We employ Postgres databases. Because it is true that Hackers or even Database Superusers in our organisation could conceivably corrupt stored data, we use automated sidechain-based checks for consistency on the state of the database, comparing end-of-previous period-state to end-of-current period-state. The difference must be computed as consistent with the immutable evidence on the sidechain. The Checkpointing cycle itself repeats at every 4 Block Commits, with the Ultimate Check occurring every 6 Checkpoints, ie many times daily. Automated alarm communication occurs upon faults being found. We also log every access to the database of any type, so all database admins’ and superusers’ actions are audited. In addition, the operational principles programmatically designed-into our cloud installations prevent dishonesty (seen as “inconsistency”) in our databases.

  Basic Principle:

  “One of the keys to Computer Security is to assume that every connecting device is potentially hostile to your system.”

  ITOTCCA undergoes full and independent database and file storage system Security Audits yearly, as well as many daily consistency tests of the database against the audit trails on the Hiero/Hedera Blockchain, with alarms reported securely, reliably and automatically by machine to our Board and simultaneously to all other stakeholders (ie to all member companies, on the offended installation(s), in the first place). Our databases are backed up every 30 minutes with copies stored at multiple sites, and not automatically connectable, which means that in the event of a data crisis (very unlikely), the latest “clean” backup can be manually restored and the system written forward from that point by re-running (de-corrupted) ‘WAL’ logs (Write Ahead Logs) to the latest ‘WAL’ file. This would restore the database to the backup just before the point of take down, so possibly up to 30 minutes work could be lost, plus the time it takes us to isolate and correct the corruption. Therefore we remain vigilant but confident.

  Finally, to summarise, our Systems are Quadruple-Networked. Firstly there is the intra-organisation Crash Fault Tolerant Kubernetes triple-database clustered network backed by ChubbyChecker. Secondly there is the Byzantine Fault Tolerant network at Federation level that supervises the organisations’ Transaction Trace Metadata. This is also backed by ChubbyChecker. Thirdly there is the Global Distributed Hash Table network, following the Kademlia XOR protocol, which allows discovery of target nodes via 256-bit NodeIds and operates within a prioritised Net Transport system headed by QUIC/H3, with second preference being gRPC/H2 and lastly falling back to TCP/HTTP/1.1 as legacy support. The Kademlia system allows us to largely avoid DNS usage. Fourthly, cross-business-network security is guaranteed by writing (and cross-checking) Merkle Root series to the Hedera Blockchain (performed by our ‘Tophat’ servers). All Trace Metadata is recorded to WORM drives (Write Once, Read Many) ensuring the archiving of all Merkle Trees/Leaves, which is then available for Forensic-level investigations as needed. Actual Enterprise Data always remains private.

  In the case of a Ransomware Hack, where (typically Russian) attackers gain access to a company’s online data, the simple strategy necessary to survive the attack is to ensure the maintenance of regular (eg. half-hourly) backup procedures which MUST store the backed-up (and, naturally encryptted) data OFFLINE so that no network connection is presented for Hackers to access backups. Thus, armed with encrypted backups, (all data both in-transit and at-rest must be encrypted, not just backups) a company can ignore Ransom Demands in the event of a successful attack, and simply restore business data from offline backups, then carry on with business (losing not more than a day’s work). Better than paying 100’s of 1,000’s or millions in Ransom to regain decrypted data from Hackers.

  It should be obvious that Business Data is very valuable, and the above simple strategy of a. encrypting all data and b. regularly backing up data to offline locations, should be Security 101 in Business. Of course, after such an attack, the company needs to harden the security of their systems to prevent further successful attacks. You shouldn’t be worrying about whether an attack might happen. Rather worry about how soon it will happen. Will you be ready? Talk to us. ‘The Minders’.

  Further, while the additional problems relating to “insider jobs” are partially preventable by our higher-level systems, by combining this security with the use of AI-led supervision of users, excursions of behaviour to criminal activities from within can be prevented (see the Elastic Company) by systems using AI that get smarter as they work.

  Tx-Rails Federations
  (Maximum practical number of federations, in terms of operational limits, is 13)

  tolerable faulty servers (f)	number of BFT network servers required to tolerate f faulty servers (n=3f+1)	Relative Risk of Initial Breach of Consensus of f+1 servers (Subsequently Detected by ChubbyChecker)
  0	1	High: 1 server must be corrupted
  1	4	High-Moderate: 2 servers must be corrupted
  2	7	Moderate: 3 servers must be corrupted
  3	10	Moderate-Low: 4 servers must be corrupted
  4	13	Low: 5 servers must be corrupted

  With all our security and anti-fraud efforts combined, we offer GOOD (Guaranteed Ownership Of Data) to your organisation as a promise that we will protect and hold safe all your data and transactions.

  We develop on Ubuntu Linux Machines (hosts) with Alpine Linux containers (on Docker and Kubernetes, on the hosts) for compact image size. We employ openSUSE Linux virtual machines.

   

  and we develop for iOS on Apple Mac: For the iOS environment of Front End DApps

  Our standard meets or exceeds ISO 27001 and ISO 27002 (Information Security Management Systems, including Best Practice Recommendations).

  Thanks to:

  the Unix Device Operating System (since it began to escape from the International Criminal (ask about the history of the Anaconda Copper Mine in Chile) AT&T’s Bell Laboratories in the early 1970’s); Ken Thompson, Dennis Ritchie and the ‘C’ programming language.

  and the Open Software Foundation (1984 – 1996), whose members helped set it free

  and The creators of O.O.P. (Object Oriented Programming – from late 1950’s), especially Bjarne Stroustrup (from 1979) the inventor of C++, which saved the developers’ world.

  and the IBM and Intel Companies for introducing the x86 PC Architecture.

  also, Apple Inc, particularly for the quality .. and for switching to a Unix Operating System (based on a fork of the open source 386BSD operating system, which is built on Objective-C ) for their own computers, for some time using Intel Chips (although this is now changing).

  

  the Free Software Foundation (since 1985)

  (not forgetting) .. Google & the Android developers, Ken Thompson, Google and the GO developers & Brendan Eich, Google and the V8 Javascript Engine developers & Google and the Kubernetes developers & Google and the TensorFlow developers. Also James Gosling and the Java! developers.

  also, of course Linus Torvalds,

  who originally licensed and studied an educational version of the Unix Operating System for PC’s (or “Microcomputers”) called “Minix” from Prof Andrew S Tanenbaum in the form of a book with included source code – on Floppy Disks – (published by Prentice Hall) for $US69, based on the 1980’s series IBM/Intel-XT Personal Computer Architecture. (Unix, more a set of Standards now than “code”, was written originally for Minicomputers and Mainframes in networked multi-user environments, but there is no reason it can’t run – when the source code is written to the Unix Standards and compiled for the IBM/Intel Architecture – in multi-user fashion on a PC, which is the same class of electronic device as any other – non ‘Quantum !! ‘ – computer). On January 5, 1991 he purchased an Intel 80386-based (“80386” CPU or processor) IBM PC XT/AT “clone” computer before obtaining his MINIX copy, which in turn enabled him to begin work on Linux. He commenced work on Linux in mid-March, 1991 (see below “Tanenbaum” link).

  MINIX:

  Relationship with Linux

  

  Early influence
  “…The design principles Tanenbaum applied to MINIX greatly influenced the design decisions Linus Torvalds applied in the creation of the Linux kernel…. Torvalds used and appreciated MINIX, but his design deviated from the MINIX architecture in significant ways, most notably by employing a monolithic kernel instead of a microkernel. This was disapproved of by Tanenbaum in the Tanenbaum–Torvalds debate. Tanenbaum explained again his rationale for using a microkernel in May 2006…” (Wikipedia)

  [ Nevertheless Tanenbaum (see the above link) admits that the demand for performance, in terms of computational process-speeds, but also in terms of speed in progress of the development effort, from users of Linux, outweighed the capacity of a microkernel system and militated in favour of developing a monolithic kernel, for practical reasons. The reasons for Tanenbaum’s preference for a “microkernel” lie in its security advantages. -Ed.]

  “..Early Linux kernel development was done on a MINIX host system, which led to early Linux inheriting various features from MINIX, such as the MINIX file system.

  Samizdat claims.
  In May 2004, Kenneth Brown of the Alexis de Tocqueville Institution made the accusation that major parts of the Linux kernel had been copied from the MINIX codebase, in a book called Samizdat. These accusations were rebutted universally—most prominently by Andrew Tanenbaum himself, who strongly criticised Kenneth Brown and published a long rebuttal on his own personal Web site, also pointing out that Brown was funded by Microsoft.

  Licensing
  At the time of its original development, the license for MINIX was considered to be rather liberal. Its licensing fee was very small ($69) compared to those of other operating systems. Although Tanenbaum wished for MINIX to be as accessible as possible to students, his publisher was not prepared to offer material (such as the source code) that could be copied freely, so a restrictive license requiring a nominal fee (included in the price of Tanenbaum’s book) was applied as a compromise. This prevented the use of MINIX as the basis for a freely distributed software system.

  When free and open-source Unix-like operating systems such as Linux and 386BSD (386BSD is an ancestor of Apple’s MacOSX -Ed.) became available in the early 1990s, many volunteer software developers abandoned MINIX in favor of these. In April 2000, MINIX became free/open source software under a permissive free software license, but by this time other operating systems had surpassed its capabilities, and it remained primarily an operating system for students and hobbyists….” Wikipedia (see “MINIX” link above).
   

  Linus went on to design and build the ubiquitous version control system known as “git”
   

  + A strong ‘Thank You’ to the Unix/Linux open-source ecosystem (since 1991), including
  All Contributors, under the various open source and free software licences, past and present.

  

  Also, many thanks to: Rong Chen and Elastos

  

  In 2000, Rong Chen, a senior alumnus of Tsinghua University’s Computer Science department, returns to China from Microsoft USA and begins research and development for the first-generation Elastos network Operating System.
  In 2003, Rong Chen was received by Jin-Tao Hu, the former CPC General Secretary.

  In 2006, Rong Chen completed the kernel and graphics systems.

  In 2007, Rong Chen built a complete smartphone and massively produced it.

  In 2009, China Unicom used Elastos’ middleware as a fertile phone operating system framework.

  In 2013, Foxconn invests in the Elastos open source project to build a distributed, cross-internet industrial Internet of Things and a smart home network operating system.

  In May 2017, Rong Chen co-founded the Elastos Foundation with Feng Han to support Elastos – a blockchain-driven Internet project, attempting to create a new digital smart economy model that turns numbers into wealth.

  In 2017, Sunny Feng Han and Ji-Han Wu started running the Bitcoin Investment Elastos Blockchain Community and an alliance with Bitmain and NEO started to take shape. Then the incident occurred.

  We have carried on, thanks to our own Risk Management Practices, including
  “ChubbyChecker“

  Also thanks to Tendermint contributors
  
  likewise to Diego Ongaro and John Ousterhout, the developers of the Raft Algorithm,
  
  and the developers of libp2p-kad-dht/kademlia following the inventors Petar Maymounkov and David Mazieres.
  

  @IT/OT Chain & CloudAustralia Pty Ltd

  ---

  Tx-Rails — Built by IT/OT Chain & Cloud Australia (ITOTCCA). Sydney · London.