A Standard Enterprise Application Supply Network Backend
Licences Offered Now!
The General, is an application that runs as an open and adaptable system. It’s Accounting with Payroll/full HR and Inventory Management (plus Purchase & Sales order Tracking). Included is a Generalised Asset Maintenance Scheduling, Inspection and Response System. Factory production scheduling and quality assurance are also covered.
The Generalutilises Permissioned Blockchains to enable advanced, auditable Trading in Services, Commodities and Items (Goods) including the production, quality control, sale and distribution, or leasing of (possibly complex) items from Farm, Mine, Quarry, Mill, Well, Nursery, Market, Construction Industry & Factory-Networks, through Wholesale-Networks, to Retail-Networks and Consumers. Items can contain unlimited-lists of assemblages of (to start with) up to six layers of complexity each, in a scope which may easily be increased to suit your needs.
We realise that Governance of a Network is of utmost importance, in many ways, and needs to be embedded in the development process as much as in production.
ITOTCCA uses Kubernetes as the Cloud-based Container Management System. Kubernetes includes Kubeflow, an add-on targeted at running Machine Learning models at full scale on TensorFlow (or other M/L platforms), on a Kubeflow node. We are currently testing open source datasets on TensorFlow on a Kubeflow node
A Kubernetes system can be built on top of an OpenStack on-premises Cloud base. We recommend the Canonical builds here, for their convenience, economy, flexibility and lack of vendor lock-in. You can employ OpenStack in a hybrid setup combining public Cloud installations where you would benefit from easier, secure global access for sections of business actvity or periods of temporarily increased IT demand.
IT <–> OT
Alternativelly, in cases where inter-business trading is desirable (eg Supply Chain applications), but the quantities of data to be stored make Blockchains impractical, we offer a system of networked databases as a Back-End, including all companies in the network with their own ‘Member Class’ servers. In our system, currently under development, entitled ‘The Bucordo Project’, the database servers are linked in networks that mimic real Blockchains, with identical immutability and security, but with huge data capacities involving no ‘mining’.
In environments with low risk of malicious behaviour internally, an algorithm by Diego Ongaro and John Ousterhout called Raft covers against crash faults by operating a replicated, all-masters set of databases with leaders who have voting “followers” (containerised apps), and “Copiers” (other nodes).
The companion Distributed Node Network to Raft, is Tendermint, which provides so-called Byzantine Fault Tolerance. BFT goes beyond the Crash Fault Tolerance of Raft, giving a certain degree of protection against both Crash and Malicious Behaviour. For the cases of Raft and Tendermint there is a residual risk of agents controlling a quorum of nodes, in which case we rely on the combined procedures of ChubbyChecker, independently and externally, running every 24 Blocks of 1024 TransactionsTraces (called a slab of transactions), keeping count of transactions and blocks, where, after ChubbyChecker has cleared all claims for a slab (involving 129 cross-checks per Transaction Trace-in-Block), the Merkle Root of the slab is calculated, then written immutably to the Hiero/Hedera Blockchain. The Roots are backed by complete records of every transaction trace (standardised excerpts of non-strategic data in a transaction). We can trace down any database-internal or -external inconsistency with this information. Alarm messages are sent via the encapsulating Kademlia DHT Network.
Tx-Rails sees neither your production schedules, your supplier contracts, your unit costs, nor your customer mix. The content of every transaction stays under your encryption.
What we see is a cryptographic envelope around each event — enough to prove provenance, chain-of-custody, and audit-grade traceability to your customers, regulators, and counterparties. Your competitive intelligence is yours; the integrity proof is ours to attest.
Also, many parties can be involved in automatically validating (or otherwise) each contract or transaction (“Smart Contracts”)
With an inter-business networked system employing Smart Contracts, productivity is increased and lost time minimised, because each transaction’s details (due to smart contract action, reliability and visibility) are mutually visible and will not need to be disputed by other parties to the transaction, removing conflict between trading partners
All parties to each transaction possess all appropriate details (and only appropriate details) for each party
The General uses …
Tx-Rails is based on a combination of the original Byzantine Fault Tolerant Tendermint Project (no mining) supervised by ITOTCCA’s own ChubbyChecker
As mentioned elsewhere, all but the minimum necessary data to provide our security services and to manage the system remains secret from us and others. You value your Information. We respect that – and we provide our services with Privacy and Security as our highest priorities. The Metadata you “channel” to us, via your devices, automatically using our Public Key for encryption, and sent to our Metadata Stores, thence Anchored as a Trace of Traces to Hiero, amounts to a list of 33 Metadata fields encrypted with our Public Key, and sent to our Metadata Stores.
In addition to these fields, any client data which is indicated by any of the following conditions will likewise be encoded with ITOTCCA’s Public Key, processed then encrypted with the Customer’s Public Key before storage.
Data Types Requiring Decryption
Spatial Data: Geometries and geospatial properties.
Metadata: Transactional and spatial metadata.
Non-Spatial Data: Attributes linked to spatial entities.
Logs and Results: Audit logs, processed query results.
Operations Requiring Decryption
Spatial queries and transformations (e.g., ST_Within, ST_Buffer).
Joins, aggregations, and proximity calculations.
Validation, filtering, and indexing operations.
Processing and formatting results for client delivery.
ALL DATA IS ENCRYPTED BOTH IN TRANSIT AND AT REST
GENERALLY USING YOUR OWN PRIVATE KEYS, BUT USING OUR PUBLIC KEY,
OR PARTNERS’ PUBLIC KEYS, TO SEND US CHANNELED, PRIVATE COMMUNICATIONS
Your set of cryptographic keys remains yours to manage with utter secrecy for different roles and users. We are not privy to customer crypto keys, with the exception of the common, business sub-network-wide, shared list of member public keys, intended to enable channeled secure and private communication.
As a Software Engineering System, Tx-Rails is based on Juju Charms, both Standard and Custom. It resides within a Charmed Kubernetes System, with several “Models”, acting as Namespaces to contain separable parts. The development is approaching a successful conclusion with the Business Process Design Studio (a Front End with GUI) now ready. The BPD Interface (BackEnd) has a number of Business Process “Atoms” (actions) to be coded, towards a final Proof of Concept. All other sections are approaching completion with the final deployment path entirely mapped out.
The overall concept is to use the core Tx-Rails code as a configurable basis which will not need to be altered for different applications. The package is designed for infinitely flexible reconfiguration. It is not even a prerequisite that an application involve a supply network, since even standalone applications (such as Real Estate Agencies (Chubba Morris) and Land Title Conveyancing (convey_IT)) are catered for. Networked applications, however are where Tx-Rails shines.
A customer of Organisation C enters an order for Z units of Product C. This causes Org C’s Database System to order X of Product B (order sent directly to Org B internal to the database supply network) to help produce the fulfilled order. The order from Org C hits Org B’s database. This causes the order to generate a call to Organisation B’s Factory Y for X units of Product B (the amount required to replenish Org C’s inventory of Product B, by the number of Units used to produce Z units of Product C). The NodeRed server at Org B’s Factory Y automatically generates an order for Y Units of Product A from Org A, which Org B requires to replenish its inventory of Product A after producing X units of its Product B for Org C. (This stage could also be accomplished within the database system, but we use NodeRed to show the capabilities of the system). NodeRed’s order hits the Load Balancer, then one of the 13 nodes and finally is received as an order at Org A’s database. Luckily for us, Org A has plenty of Stock to produce Y units of Product A. The units are delivered in short time. Meanwhile Org B has produced and delivered the X product B units to Org C (having sufficient Inventory) and Org C has also shipped the Z units of Product C (also with sufficient Inventory). All inventories are already topped up.
In a Supply Network situation such as this, most operations involving data processing can be handled internal to the databases, with the generation of production activities, including data recording, involving systems such as NodeRed, and connected Mechatronic Equipment (such as Bosch/Rexroth’s Ctrl-X 6-axis movement automation platform), in communication with the databases.
Payments are completed within the few seconds it takes for transactions to be processed, upon acceptance (but only if accepted) at delivery and other check points. QR code technology is applied, so labels are simply “flashed” by a reader upon acceptance. Rejection is handled by a separate operator controlled “soft-button”, on an Android or iOS mobile Tablet device, with selected/entered reasons for rejection, and scope for photographic, audio or video references to be attached and uploaded to the Elastos “Hive” IPFS system (to outline just one Use Case).
Real Machines, Devices and Objects can become part of the Internet Of Things, enabling Automatic Quality/Location/Dimensions/Safety/Other Control Smart Contracts
These contracts can be integrated into a production/distribution or maintenance system
Other advantages include the offer of Distributed (Shared) yet Private Ledgers, with our use of “Channels”.
Tx-Rails sees neither your production schedules, your supplier contracts, your unit costs, nor your customer mix. The content of every transaction stays under your encryption.
What we see is a cryptographic envelope around each event — enough to prove provenance, chain-of-custody, and audit-grade traceability to your customers, regulators, and counterparties. Your competitive intelligence is yours; the integrity proof is ours to attest.
Continuous cryptographic audit for the plant floor — without ripping out your PLCs, your SCADA, your MES, or your historian.
A manufacturing operator’s audit obligations have multiplied while their IT footprint has not. ISO 22000 wants traceability from raw material to retail shelf. ISO 9001 wants documented evidence of every process deviation. IEC 61511 wants verified integrity of safety-instrumented functions. The customer’s procurement team wants Scope-3 emissions data. The regulator wants recall-readiness evidence on a 24-hour clock. Each of these audit obligations lands on the same plant-floor data — PLC tags, sensor readings, OEE calculations, batch records — and each one asks the same question: *”prove this happened, prove it wasn’t tampered with, prove the timeline is real.”
Tx-Rails is the substrate that makes those proofs cryptographic. It sits **underneath** your existing MES, SCADA, historian, batch-record system, and ERP — binding to them via change-data-capture or atomic dual-write — and produces a tamper-evident, jurisdiction-independent audit trail for every event a regulator or customer auditor would want to verify. We do not replace your existing systems. We make their outputs cryptographically provable.
_________________
What we capture
Raw plant-floor telemetry — the 1 Hz PLC scan, the 10 Hz pressure transmitter, the 100 Hz vibration monitor on the spindle — stays in your historian. That’s where it belongs. Tx-Rails captures the events derived from that stream that have audit consequence.
Equipment Provenance
Device registration** — every PLC, RTU, HMI, controller, sensor, actuator, and edge-compute node catalogued with manufacturer / model / serial / firmware version / protocol (Modbus / Profinet / EtherCAT / OPC UA / MQTT / DNP3) / ISA-95 level
Sensor channel definitions — every tag with unit, expected range, sample rate, warning + alarm thresholds, version-controlled and auditable
Firmware updates with binary hash and signature verification — provenance for cyber-supply-chain compliance under IEC 62443 and EU NIS2
PLC program changes captured separately with checksum verification, change reason, approver — the Stuxnet-class risk surface
Quality & Calibration
Calibration events for every instrument with traceability to NIST / NMI / ILAC / customer reference standards, pre and post deviation, next-due date — ISO 17025 evidence
Setpoint and threshold changes — every control-loop setpoint, every alarm trip point, every interlock condition, with prior and new values, change reason, approver
Anomaly events — deviations from baseline detected by ML model (predictive maintenance), statistical method (SPC), or rule-based system
Operations
Alarm events with severity (Info / Warning / Alarm / Critical / Emergency, aligned with ISA-18.2 alarm philosophy)
Operator acknowledgement of alarms — who saw the alarm, when, what action they took, whether they escalated
Commands issued to equipment — every emergency stop, every interlock bypass, every batch recipe load, every mode change, with operator identity, auth method, and execution outcome
Health indicators per device with 0-100 score, trend direction, and remaining useful life estimates — the predictive-maintenance signal
We do not replace your SCADA, your MES, your batch record system, your LIMS, your CMMS, your ERP, your historian, your data platform, your PLC programming environment, your HMI development tooling, your OPC UA server, or any of the device-level firmware. Every one of those is a deep operational investment your engineers and operators understand intimately. Tx-Rails sits underneath them via one of three integration modes — hash-only attestation, atomic dual-write, or change-data-capture observation — and produces continuous cryptographic evidence that the state changes those systems record are real, ordered, and unalterable.
This is the underlay positioning. It is the only positioning that survives a Plant Manager’s first question: *”how much line downtime is involved?” Answer: none.
_________________
Three forces, one architecture
Regulators ask for continuous evidence, not periodic attestations.** Food-safety auditors used to come once a year. Recall preparedness drills used to be quarterly. Both are sliding toward continuous. The plant that can answer *”prove the temperature in zone 4 never exceeded 4°C in the last 90 days, and prove the alarm logs weren’t post-edited”* with a cryptographic verification has a fundamentally different audit profile than one that can’t.</span
Customers ask for upstream-chain evidence.** Every retailer, every distributor, every contract manufacturer is being asked to demonstrate Scope-3 emissions, lot traceability, and contamination history from their upstream suppliers. The plant that can publish cryptographically signed evidence — not screenshots, not PDFs — has a procurement advantage. The plant that can’t is incrementally losing market share to one that can.
Cyber-supply-chain compromise is a board-level risk. IEC 62443. EU NIS2. The new CIRCIA reporting regime in the US. All converge on the same requirement: prove the firmware running on your plant-floor controllers is what the manufacturer signed, and prove no unauthorised commands have been issued. Continuous cryptographic logging to an independently verifiable substrate is the only mechanism that survives the breach.</span
_________________
Architecture, briefly
Off-chain — Your historian. Your time-series database. Your batch record system. Your video. We do not duplicate any of that data.
On-chain — The audit-bearing events derived from that data: commissioning, calibrations, setpoint changes, firmware updates, PLC program changes, alarms, acknowledgements, commands, anomalies, health indicators, maintenance triggers, compliance attestations, data integrity checks, cybersecurity events.
Anchored — Every block of audit events is committed to a Byzantine-fault-tolerant validator mesh and periodically anchored to a public DLT (Hedera) for jurisdiction-independent verifiability. An external auditor can verify the audit trail’s integrity without trusting the operator at all.
The on-chain audit volume is bounded by event rate, not by sensor rate. A plant with 50,000 PLC tags scanning at 1 Hz produces a few thousand audit-bearing events per day, not 50,000 × 86,400.
_________________
A note on the trust boundary
The conventional approach to plant-floor audit is to log everything to a local SIEM and trust the operator. That works until the operator is the one being investigated. The conventional approach to integrating a public blockchain is to put the data on it. That works for nothing at industrial volume.
Tx-Rails takes a third path: a Byzantine-fault-tolerant audit mesh, owned and operated by the customer organisation, with independent auditor nodes that don’t share a failure domain with the workload nodes. Periodic cryptographic anchors are published to a public DLT for jurisdiction-independent verifiability. The trust boundary is exactly where it should be — at the math, not at the operator.
_________________
What we’d ask of you to start
A single production line. Read the audit-significant events out of your existing SCADA / MES via change-data-capture; flow them through tx-rails for one line, one production shift. At the end of the shift you have a cryptographically verifiable audit trail of every setpoint change, every alarm acknowledgement, every PLC program touch, every operator command issued. We then have a real conversation about what that’s worth on your next ISO 22000 audit, your next customer Scope-3 inquiry, or your next regulator-mandated cyber-readiness drill.
[Contact ITOTCCA →] john@itotchaincloud.com.au
Tx-Rails Smart Contracts for General Manufacturing
Supplier payments, quality milestones, equipment-as-a-service, and recall execution — all running as self-executing multi-party contracts with full audit trail.
Manufacturing runs on agreements that span tiers. A tier-3 commodity supplier ships steel to a tier-2 forging shop; a tier-2 machining shop delivers components to a tier-1 systems integrator; a tier-1 integrator ships subassemblies to the OEM; the OEM delivers a product whose warranty terms involve a downstream service network, a recall reserve, and a leasing arrangement that ties revenue to actual runtime. The agreements exist on paper. The execution is hand-coordinated email-and-spreadsheet work, with disputes that take quarters to resolve and reconciliations that lag the underlying events by months.
Tx-Rails now turns those agreements into **on-chain smart contracts that execute themselves** when their conditions are met. IIoT telemetry triggers condition resolution; multi-party signatures release escrowed funds; quality, delivery, and runtime events drive payment automatically — all recorded with cryptographic evidence of which rule fired, which event triggered it, and who authorised the underlying agreement.
_________________
What you can now automate
Pay-on-quality supplier settlement
A tier-1 forging contract pays $48,000 per batch — but only after the batch passes incoming-inspection. Today: the receiving QA lab inspects, marks a paper traveller, finance gets the news four to six weeks later, the supplier waits for payment, the supplier-finance team chases the AP team, and friction accumulates.
With tx-rails:
The PO is issued as a **multi-party transaction** between OEM purchasing, supplier sales, OEM QA, and (where contractually required) a third-party inspection authority.
The $48,000 sits in **escrow** at GRN — co-signed by all parties at the time of order.
A **release condition** is attached: “incoming inspection PASS” — predicate evaluates against the inspection record’s pass-status field.
When QA records the inspection, a **workflow rule** fires the moment the result lands: PASS → condition MET → escrow releases → AP posts payment to the supplier the same block, with full dimensional accounting (cost centre, project, fund) preserved.
FAIL → condition FAILED → workflow auto-opens a quality dispute and the funds are frozen pending arbitration.
Equipment-as-a-Service (pay-per-runtime)
A CNC machine OEM leases equipment under a runtime-tier pricing model: $X per spindle-hour up to threshold T, $Y per hour above it. Today: the OEM trusts the customer’s monthly self-report; the customer disputes the OEM’s read of the controller; both sides reconcile quarterly with margin loss baked in.
With tx-rails: the machine emits hourly **telemetry aggregates** (sample count, spindle-on hours, anomaly count) to the ledger. A **workflow rule** matches each aggregate, computes the runtime-tier-aware charge, and auto-fires an invoice action against the customer’s payment terms. The customer’s CFO sees an invoice that resolves to specific telemetry-aggregate IDs; the OEM’s CFO sees revenue recognised against actual usage; the auditor sees the rule, the predicate, and the matched event recorded in the same block.
Multi-tier subcontract milestones
An OEM contracts a $14M aerospace subsystem with a tier-1; the tier-1 subcontracts $4.2M of machining to a tier-2; the tier-2 sources $640K of raw forgings from a tier-3. Today: payments cascade by phone, with tier-3 paid 90+ days after tier-1 receives, even though the materials are in-house.
With tx-rails: each tier’s payment is a **commitment group** keyed to a verifiable upstream milestone (FAI completed, first-article approved, dispatch confirmation, GRN at next tier). The tier-2’s payment to tier-3 is an escrow that auto-releases when tier-2’s own GRN action records receipt-with-inspection-pass; the tier-1’s payment to tier-2 auto-releases when its own FAI assertion lands; the OEM’s payment to tier-1 auto-releases against quality + delivery milestones it co-signs with tier-1’s PMO. Working capital across the supply chain compresses from quarter-end reconciliation to same-block settlement.
Recall execution with multi-party co-signature
A safety-critical component is recalled. The OEM has to coordinate with the tier-1 supplier (root cause), the tier-2 (forgings the tier-1 won’t return without payment), the customers in-field (replacement scheduling), and the insurer underwriting the recall reserve. Today: weeks of conference calls, fragmented spreadsheets, and a recall scope that creeps because nobody trusts each other’s data.
With tx-rails: the recall is a **multi-party transaction** with commitment groups for OEM, tier-1, tier-2, insurer, and (in regulated industries) the safety regulator. The **batch tracking** already in the inventory ledger locates every affected unit across every customer. As each customer-side replacement lands, a **workflow rule** matches the stock-receipt event, fires the corresponding insurer-payment-release action, and auto-credits the OEM’s recall-reserve account. Every party sees the same recall progress in real time; every payment has cryptographic provenance back to a specific replacement event.
Outage-credit automation
An SLA between a critical-equipment supplier and a manufacturer specifies 99.5% uptime, with credits for downtime past that threshold. Today: monthly uptime reports get argued over for weeks, with the supplier’s view and the customer’s view never quite matching.
With tx-rails: the equipment’s IIoT telemetry aggregates uptime per shift. A **workflow rule** evaluates monthly aggregates against the SLA threshold; if the threshold is missed, the rule auto-fires a credit-note action against the supplier’s next invoice. Both CFOs see the same number, derived from the same telemetry, with the same audit trail.
_________________
Why this matters
Working capital is leaking into the reconciliation cycle.** Every day a payment is held up by manual quality-verification or inspection-sign-off is a day of working-capital cost the buyer eats and the supplier finances. Automating the release the moment the condition is provably met shrinks that cycle from weeks to blocks.
Quality disputes destroy supplier relationships.** When a buyer holds payment for “quality issues” the supplier doesn’t recognise, the relationship corrodes. When the release condition is a predicate against a specific inspection action both parties co-signed in advance, the dispute lifecycle is structured, auditable, and bounded by the on-chain arbitration framework.
Tier-N transparency was always a fantasy.
The OEM never really knew what tier-2’s quality looked like, because tier-2’s evidence was opaque and tier-3’s was invisible. With each tier’s actions recorded on the same multi-party ledger, and with workflow rules cascading through the tiers, the OEM can write smart contracts that depend on tier-2 events without trusting tier-2’s IT.
The audit is built in.** Every auto-fired payment, every released escrow, every triggered workflow rule has a cryptographic provenance record. SOX, GMP, ISO 9001 / AS9100 / IATF 16949 auditors can verify a year’s worth of supplier-payment activity without trusting anyone’s internal spreadsheets.
_________________
What this doesn’t replace
We don’t replace your ERP, your MES, your supplier-collaboration portal, your QMS, your TQM platform, your maintenance management system, your inventory system, your contracts repository, or your treasury system. Tx-Rails sits **underneath** all of them as the multi-party-aware execution substrate. The smart contracts run as on-chain logic against the events your existing systems already produce; the payments post back into your ERP via the dimensional-accounting layer so your CFO sees normal journal entries with full provenance back to the underlying manufacturing event.
Indicative Pricing (p.a.)
Industrial IoT
Tier 1 Upper Band
A$1M – 3M
Smart Contracts
Tier 1 Upper Band
A$1M – 3M
◦
Tier-3
single-site
1 pyramid
1-2 federations (Shape 1)
◦
Tier-2
multi-plant
1-2 pyramids
3-5 federations (Shape 2 grouped)
◦
Tier-1
multi-jurisdiction
3-5 pyramids
5-10 federations (Shape 2 or 3 sovereign)
Please refer to the Federation Trust Model page for explanations of Federations, Shapes and Pyramids.
As a Supply Chain Network, if T = the maximum Total number of all member-classes on all commercial networks at any particular month, the General (excluding Automation/Artificial Intelligence) licenses for between $USD1.0 Mill and $USD3.0 Mill per annum per member.
If you require Industrie 4.0 Standard (IoT/OT/AI) we can still act as the core enterprise accounting application provider, with you developing your Industrie 4.0 Project via your chosen AI/Tooling provider(s) on our specific Blockchain-networked Database Security System, so that your deployed M/L models are totally integrated with the Enterprise DApp, and connected to your Kubeflow/TensorFlow (AI) node, and indirectly connected to your trading partners (other members) for operational matters.
However, as a counter-example, a Real Estate system would not be a trading network. It would require at least 2 or 3 member classes to constitute a real economic supply chain network of any description.
An example here, of adapting for efficiency, might be to broaden each individual primary industry DApp and Schema in a Supermarket supply-chain application, to include all other primary industries, and integrate into one application (primary-level-DApp), employing roles within the DApp to differentiate between primary industry types.
This idea might be seen to be almost ‘inverted’ in the case of the Petrochemical industry, where the concentration of economic power is at the Primary Production end of things. In this environment there may be concerns relating to finding more flexible and accurate ways of responding optimally to, say, short, medium and long term demand expectations. If an AI system were ‘hooked up’ to The General, changes (current and predicted) in world conditions, could influence the optimum production locations and rates to be fed directly, via Node-Red organisation and networking and ctrl-X (and other) systems, into mechatronic production hardware control implementations – reaching the field almost instantaneously. In addition, the Industrie 4.0 approach to predicting machinery problems and failures, can extend the optimality of production and minimise losses, by organising maintenance, and reorganising production and distribution as diagnosed by the AI system, in response to in-field conditions, involving data collected and communicated continuously from the sites’ hardware and machinery, and control data being communicated back to machinery in the field after AI analysis.
Also, in the manufacturing industries, some dynamic and fruitful results are to be found, as the abilities of our systems to provide secure and private inter-business networking, supply-chain provisioning, and trading, come to the fore. Business automation becomes possible, not merely in the technical arenas, but in the accounting/payments/auditing, ordering & supply-control spheres that operate between companies. It is possible to control the fluxes of products and inputs for manufacturing endeavours, according to exigencies such as machinery malfunction prediction and adaptation, and demand variation, with the goals relating to minimising losses and improving responses to events, being “understood” by Machine Learning and AI, and applied to analyses of historical and current data. The degree-of-understanding achievable in these ways, is far greater than any levels attainable by human analysis and adaptation alone.
The construction industry provides another example of the potential of ITOTCCA systems. There is a range of suppliers for any construction project, all of whom need to be coordinated and guided to enable timely supply of materials, equipment and services. The benefits to be obtained by employing a system such as we offer, where even complex goods can be produced, tracked and, finally, installed and paid for – on schedule – are hard to ignore. There is no need for arguments about order types and quantities, or other details, nor about agreed timing (allowing for weather of course) since the system utilises a network of database servers that mimics a blockchain, thus bringing with it benefits such as immutability of records and mutually visible details, as appropriate (yet keeping private details private). Payments can be controlled by smart contract action, where multiple parties may participate in single transactions, in the same fashion as Blockchain smart contracts (such as Ethereum) but with unlimited data storage capacity (unlike Blockchains). When you add to these factors the unbeatable security of our cyber systems, backed by the use of 2 blockchain “brands” for separate security functions (Elastos for Authentication and network transport security, and Elastos for Financial/Critical Transaction cross checking and validation), we hope you will agree that ITOTCCA presents a very compelling option.
To anyone involved in the Health Sector, it comes as no surprise that there is a broad network of Supply-Lines involved in the delivery of safe clinical care. From parts for air conditining equipment cleaning and maintenance to supplies for operating theatres, and far beyond, the requirements for the continuous and reliable supply of high quality inputs are always demanding. Automated and secure Supply Chain networking is desirable. We can make it as affordable as it is secure.
A sample of suggested types of (simplified) use cases for The General, is shown in the following 3 screenshots, where the Head company initiates some Jobs, and we show a range of possible control and communication flows within Supplier companies in the second and third shots. Job 1 is a product test, while Job 5 entails the manufacture of 3 sub-assemblies, by 2 different supplier companies. Job 2 comprises a somewhat more complex set of Electro-Mechanical Unit Tests.
“The Aerospace Industry provides many examples of Inter-company supply and trading networks. The wide variety of products and parts that are needed to complete the successful production of finished Air and Space craft can only be achieved by the cooperation of many companies worldwide.
Our cyber systems can provide the security, product-quality assurance, convenience, strategic enablement and usability demanded by the Accounting, Technical and Non-Technical Executives and Administration staff of member companies. Our server networks will be located in data centres around the world, all running by the principles outlined in an IBM article entitled Blockchain Meets Database: Design and Implementation of a Blockchain Relational Database. We have a private code repository where we are developing with a foundational Control-Forte/Control-Finte/Health/Housing system as a 4-cluster network-of-networks, using k3d (Kubernetes on Docker) software, with BFT-SMaRt transaction ordering and replication, and employing Terraform (Infrastructure as Code).
Using databases as de facto blockchains has many benefits, as detailed herein. By adding an Ultimate transactional cross-checking system (ChubbyChecker), and by combining all segments within Distributed Hashtable (DHT) Kademlia server networks, we have attained an unbeatable level of security that avoids the high-risk Domain Name System (DNS) for all but Banking transactions, email and any necessary traditional web services.”
This is responsive AI-led production, backed by a secure set of immutable audit trails, and based on Trust paid for by our investment in Hedera DLT fees providing a built-in insurance guarantee against a global fiat currency collapse by using Cryptocurrency (eg Hbar). When you add to that the revolutionary ultra communications security enabled by the DHT System (the Kademlia DHT networks mentioned above), the argument becomes more compelling. The hole in the would-be iron-clad system, is the factor of trust demanded by the providers and administrators of the Centralised or on-prem Cloud Database system, in a setup we call Hybrid Web2/3, which computational and network efficiencies simply do mandate. That is to say, current capacities of networks, Client devices, and Blockchains are not sufficient to enable storage of Enterprise quantities of Data, On-Chain. We continue to require databases.
c
~ ~ ~ ~
Our solution to this question of trust, is to follow the IBM India lead, and develop a mutually assured Zero Trust system involving all database servers in blockchain-style Transaction-replication business-networks, which are designed to keep all players honest programmatically.
In an overall sense, the procedure is guaranteed by our practice of forming and recording Merkle Trees from Blocks of Transaction traces, followed by calculating the Merkle Roots of the Trees and recording them, one Merkle Root per ‘Slab’ of 24 Blocks of 1024 Transaction Traces, onto the Hiero Blockchain. This is part of the operation of the ChubbyChecker package.
The process anchors the data in a way that is immutable and re-checkable, so we can check for the presence of corruption. If inconsistency is found upon checking (which occurs on every occasion of recording a new Root, since the previous Root’s value can be extracted from the current Root value), alarms are automatically multicast to affected members. A Root Cause Analytic Procedure follows, led by our company, pending an “all-clear” and restart of interrupted production.
~ ~ ~ ~
with Kademlia/QUIC/TLS1.3 network transport security
Hiero/Hedera Blockchain
Replicação da máquina de estado bizantina para as massas Byzantine State Machine Replication for the Masses
+ India Research भारतीय अनुसंधान
IT/OT Chain & Cloud Australia
Peace on Earth. Compassion. Sustainability. Deterritorialisation.
IIOT
Elastos Carrier2: Client-to-BFT-SMaRt/Database
ChubbyPreRegister ChubbyPostRegister ChubbyChecker: Hiero Blockchain vs Database:
Bucordo Security (Tendermint) merged with Carrier, and:
“ChubbyChecker“
Elastos libp2p-kad-dht Transport, End-to-End Encryption, 6-Stage x 129-Factor Cross-Checking, No Operator Read Access, No Operator Write Access
“BFT/DHT BUCORDE”:
Triple-Networked
Striving for the Gold Standard
Zero Trust,
Zero Tolerated Faults,
Utter Data Privacy
Total Absence of DNS
(ADNS)
Sensors Actuators Devices Machinery
“to Fail Safely”
authors of
.. but sitting in the Clouds, appropriating our data .. and selling their inferences ..
Why do people with Accountancy & MBA degrees get to make technical decisions that impinge upon the value, quality, safety, sustainability usefulness & security of products and services? They, too, are sheep feeding on fermented grass. Quality flawed by Design. Design flawed by Accountants
Code GUI’s .. with Ionic
..
..
Save resources ..
.. containerise with
Honor Ut Filiae Non Lucis Honores. Ambulate.
‘Treaty Yeah’
‘Honour Not Reward’
‘Walk As Daughters Of The Light’
ایمان، اتحاد، نظم
ChubbyChecker records Transaction Traces for ongoing comparison with database status reports. In addition we involve the owners/executives of all companies in participation in the multiple daily Database Consistency Checks, with automatically broadcast Trust Alarms in the case of any discrepancies or suspected attempts at theft or fraud, if/when detected by reference to transaction traces on the Blockchain record (in comparison to reported states of the database), as well as those inconsistencies indicated by the database system itself. These reports are based on the Hedera Blockchain as ultimate & immutable source of Truth, with the Hedera system itself ultimately guaranteed by a combination of Byzantine Fault Tolerance, backed by a Governance system overseeing the Proof of Stake controls that effectively prevents collusion of the “33%”-style-of-corruption, amongst Stakeholders. ITOTCCA directors are bound to follow-up database breaches immediately, and when it is possible to determine the company or companies affected initially, a further notification is sent to the relevant CEO, CFO, CIO and nominated officers. If further investigation is required, and no details of client companies, who appear to be involved as victims, can be determined initially, the automatic notification will have been sent to all client companies, followed by progress updates.
We perform a Root Cause Analysis and publish the results to all client companies affected, as quickly as possible. As all operators of our databases are fully aware that any attempts at Fraud perpetration will be detected automatically (100%),it is highly unlikely that there will be any such attempts. We remain vigilant, nevertheless.
It must be noted, however, that this does not constitute the conferring upon client companies an immunity to internal Fraud or Embezzlement, which ITOTCCA simply cannot guarantee against. Our guarantee amounts to an assurance of External Consistency, beyond the walls of your company, and extending as far as the prevention of undetected Database Operator or other External Fraud (Hackers) in relation to Member Class database networks. Your own internal & external auditing, vigilance and a sound company culture, are the only weapons against such internal losses, via the myriad of possible criminal schemes. At least we can confidently say that Network and Cyber Security can be ensured by employing the Elastos DID System (for authentication), and Hedera for cross checking database transactions, and that all Transactions will then be (in the words of IBM) “Non-Repudiable”, and verifiable, as each one is accompanied by the digital-crypto signature of the client/user, and all financial/critical transactions (as defined by customer companies) are registered initially at submission time, then upon execution, next at committal/roll-back, and finally cross-checked against the Hedera Blockchain to determine if any inconsistencies exist.
You may have noticed the reference to “No Operator Read Access” and “No Operator Write Access”. This means no company’s data can be accesed for READ or WRITE purposes by an operator. We were working to employ “Homomorphic”“Client Side Encryption” for all customers. However, apparently, even simple 1-second plain text operations can take more than one week to complete if homomorphic encryption methods are used. So we are returning to a regime where WRITE access by non-users (eg Operators), to user tables, is totally disabled, and there will be no need to notify Company Officers upon the logging of any READ access to a customer’s table(s), since all private data will be encrypted (non-homomorphically) with keys possessed by customer companies alone.
Our systems do require access, however, to some unencrypted datafields in order for database security checking to function properly, but with non-homomorphic client-side encryption for any important confidential fields (as defined by the customer), that do not enter into data security computations. Fortunately, the data access required by our security functions excludes most of your data, as a very tiny subset only is required by our security systems, and none of that seems confidential in any way (at least to us, at this point), being more in the realm of system-technical data. Remember that our GOOD agreement gives your data pride of place (unlike with Microsoft and Google, for example, who are scrambling currently, to be able to analyse your data for their purposes (driven by greed and the amorality of Accountancy) without decrypting it somehow – in fact anyhow if it can be done legally. This explains the intense research being done into methods allowing a practical equivalent of homomorphic encryption).
Note that the companies in any particular member class (whether sharing the same server or not), in an internetworked application (ie an inter-business trading or supply chain application) will look up and use an intended communication partner’s Public Key in order to send a communication only decipherable by the partner. Directors, Operators and Employees of ITOTCCA will still not have access to any Private Keys.
What companies stand to actually gain from our processes, comes down to the way the Virtual Machines on the database nodes are designed to automatically keep each other honest, with the backup of ensuring Utter Honesty via our proprietary Ultimate Checking System. To explain, our System also operates automatically on those same virtual nodes, policing, at 100%, any “escapes” from the main Trust-Enforcing System (designed originally by IBM, but only as effective as any Byzantine Fault Tolerant system can be). With criminal collusion of operators &/or hackers, it would be possible to “override” the IBM security design. However, by performing our own checks against trace records, of all original financial and otherwise critical transactions (as defined by you), made on the Hedera Blockchain, we prevent any such “escapes” from being perpetrated without knowledge of the crime(s) amongst the stakeholders. Such crimes will be automatically notified by alarms broadcast on the secure Kademlia System, to all those affected, within minutes of being committed. Thus, as long as all Payment Gateways to finance facilities in Suspicious or Rogue States remain blacklisted by default at the Cloud Site, the system is secure, since database operators will not have access to alter black or whitelists – an activity in the domain of the customer company only. We add to this, the impenetrable network transport security provided by Kademlia/QUIC, which bypasses the traditional Domain Name System (DNS), to emerge with a guarantee of “Total External Security” of all your database and data transport networks, outside your company walls.
As explained on the Agreements page, and above, we cannot do more than this as far as providing guarantees, since it always remains possible to defraud a company from within.
If your situation demands more than 12 Member Classes on your Business Sub-Network, please refer to the Bucordo Project page for an outline of the methods we employ to handle this.
To take the example of Disease-based Support & Sponsorship Associations, it may be possible to create a “super” association for IT purposes, let’s call it a group, such that each individual member association has its own singular-company member class server, but where these associations take advantage of the similarities in their “IT Missions” to make savings on the basic application costs, and enter into a networking of their own On-Premises Cloud Servers. In this fashion, the costs of purchasing Initial Development, Trust and Security services can be shared, whilst each Association retains its own server and its own crypto key. In this case, although each member class has exactly one member company, being more expensive than multiple-company member classes, the overall number of member classes involved is still able to create savings (please refer to the price table, above, on this page).
You should realise that our central replication and transaction ordering application, Tendermint, will tolerate global-scale server separation and still function correctly. This means it is possible for global-sized server networks, connected under Kademlia, to be interconnected in nets of common interest groups, such as the Disease Support and Sponsorship Associations just mentioned, and for those geographically diverse members to run their own Member-Class Servers on their own premises, joined to each other for replication and database security assurance, albeit separated geographically to varying extents. The fact that the intercommunications are shielded by Kademlia, makes the networks ultimately secure, not even presenting normal Http connections or websockets to hackers, and using Kademlia’s own global network encrypted node-numbering system for “addressing” purposes, bypassing the usual DNS (Domain Name System).
Productivity for Lease
with Generalised Functions that can be Adapted
For those running Ubuntu Linux, an introductory dApp (Front End) is available for inspection and trial at “The General”. On Ubuntu, with git, node.js, go, ionic and cordova, the repo can be cloned and run from root directory (see README.md on the site). Note there are many shortcomings compared to a fully functional dApp as we are still developing The General as a foundational template.
Here is a screenshot of one of the Member Class dApps so far:
The following image is a representation of the recent state of our Backend development platform. The linked “bucordo” repository reflects this layout in code. “Bucordo” also includes the Ordering and Replication Service (shown in the next image), which guarantees Mutual Trust despite basically existing in a Distrusting environment. It is fully IoT ready. ITOTCCA has overlaid our own proprietary “Ultimate Check” across a traditional Byzantine Fault Tolerant system to achieve an effective Zero-Tolerance of Database faults, whether due to Technical or Malicious reasons.
The next image details the Bucordo and Industrial IoT systems backing The General. Bucordo is about Replication and Transaction Ordering by programmatic consensus among mutually distrusting nodes (server-installations) with each server installation existing at the Member-Class level.
“
Opportunities
Do you have an idea for a commercial Business Network for which you could envisage a Front End App .. if only someone had the “Backend” Accounting Database expertise you need .. ?
Guess What??
“We’re here!”
We are offering Licenses for our System, ‘The General’, an adaptable Enterprise Accounting Application Backend.
We develop on the back of a Postgres database (which we collaborate on), and generate a front end client DApp from our definitions and “chaincode”.
The Front End (that we adapt to your needs) accesses the Blockchain Ledgers via Backend gRPC, and connects to File and Relational Database storage via middleware in GO.
The Middleware – residing on a router in front of the database server – is developed by us (in Java) to match the Front End app, acting as a sort of secure & fast ‘bridge’ between front and back ends.
Your Front End, which we develop in collaboration with you, accesses this backend gRPC system to create, read, update & delete records (and query or search them) while controlled by the database’s transaction/contract functional logic.
ITOTCCA provides full support as per the Response-Time Priority Agreement, to ensure the success of our Project.
If you have the vision of a Commercial System or Network that is independent, sustainable & marketable, we will support its development according to agreements between you, the other founding Members, and us.
You will need sound commercial ideas and a viable Business Plan.
~ “Your Network Idea. Members benefit. Customers benefit” … ~
Block ‘n’ Tackle incl Football logo: TM Registered
The General Package:
Adaptable, comprehensive Accounting, with Budgeting, Forecasting, Inventory, Payroll & much more.
Integrated Tasks, Reminders & Calendar.
Uses a Role system to cater for different departments and levels of authorisation.
Your Tech Help and Support Desk will be available 9am – 8pm Mon – Sat Sydney Time, offering help with your application, including report design and building
The General will be operating 24/7 all year long barring Technical Issues
Email: john@itotchaincloud.com.au
IT/OT Chain & CloudAustralia
“INFRASTRUCTURE”. ITOTCCA, HEDERA provide a fully functional Backend, including HEDERA Blockchain & ready to connect to the Postgres database.</li
Our sage use of GO and JavaScript and their non-blocking input/output means your app is very quick
Customer Relations Management, Sales & Orders, Purchases & Orders, Automated Banking and BPay with Barcode-scanning.
We employ the services of qualified, experienced and practising Accountants, Engineers and Sales People as our consultant “Beta-Testers”, in a continuous feedback process. We are constantly tuning the application and database.
Executive Summary
Summarising, what you get is a system that enables automated trading using Smart Contracts that are enacted on a private network, and where, due to the ability to share information with supply/health partners, using asymmetric cryptography, and also due to all database clusters acting as Masters in replication procedures, a partner organisation can access the shared data on their own local server. Sharing may also be completely revoked.
You also get a comprehensive Enterprise Application that works on Mobile devices and provides all accounting as part of the package, where the database we use (PostgreSQL) has zero licence fees, yet we can offer a 99.999% uptime guarantee (with Enterprise DB Support), excluding any down time due to the perpetration of “external” fraud (which will be detected by ChubbyChecker within minutes) and the subsequent investigations. The accounts system can be interfaced in a READ-ONLY fashion to your broader system. Or you may choose to convert all accounting to our system – which is quite possible and will be cheaper, and more secure, in all likelihood, than your present systems. We have the detailed understanding of Accounting Systems necessary to have built a fully integrated system from the ground up – we do not need to “partner” with insecure vendors, relying as they do on inferior software.
In addition you receive an economical and very security-conscious system, incorporating our ChubbyChecker Ultimate Cross-Checking package, which fills the security gap inherent in stand-alone distributed systems that employ either Crash- or Byzantine Fault Tolerance, as well as all the normal security measures such as client-side end-to-end encryption, together with the absence of risk of Man-In-The-Middle and Denial-Of-Service attacks (with our use of libp2p/Kademlia, bypassing, as it does, the normal Domain Name System – DNS). The distributed nature of the system is what allows the operation of private-networked Smart Contracts, incorporating unlimited volumes of data per contract (and overall), and also it is what allows the secure sharing of information, as necessary, to enable business/health operations to function efficiently.
But what is the magnitude of the risk against which we are protecting? According to an independent analyst organisation (Analysis) there were 25,949,000 personal records compromised in the healthcare sector in 2023 alone. “These are often called ’supply chain attacks.’ In fact, it is not just one customer that can be attacked, but essentially every customer that uses an (inferior) vendor’s services. Thus, a single vulnerability can threaten many thousands of organizations, such as in the 2023 MOVEit attack where already over 2,600 companies in more than 30 countries admitted to being attacked, with more than 80 million individuals’ data being compromised. In fact, 98% of organizations have a relationship with an (inferior) vendor that experienced a data breach within the last two years. In some studies, the number of data compromises due to supply chain attacks in 2023 jumped 78% over 2022.” Stuart Madnick – Harvard Business Review The problem is no longer a case of “if” but now a case of “when” will your systems be attacked.
There are many vectors by which attacks may be mounted. Our use of kademlia avoids some, however, still, the most common and “fruitful” means of attack involve targeting individuals using Social Engineering. As an example of Social Engineering, the attackers may use knowledge gained in any fashion about an employee’s vulnerabilities, contacting that employee and using this knowledge to obtain the employee’s cooperation in an attack or in the exfiltration of information from your database. It is very important to have multiple offline data backups in place in the case of an attack, which may also arrive in the form of Ransomware. The basic process involves the attackers accessing your data and re-encrypting the data to prevent your access, then demanding a Ransom for decrypting the data. If you have a good back-up system, and your data is strongly encrypted, this is simply not a problem. Note that the backups need to be kept offline and thus inaccessible to an infiltrator online.
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 encrypted) 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, originally stolen by Hackers.
Security 101 in Business
– – 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. – Talk to us. ‘The Minders’.
– – While the additional problems relating to “insider jobs” are – partially preventable by our higher-level systems, by – combining our 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. These systems get smarter as they work. – Also consider the number of people who send passwords via email to themselves as a record, or to others to access their account in an “emergency”. If these emails are compromised in external third-party attacks outside your system, your system may become compromised by a malicious agent. This touches on the concept of an Attack Surface, meaning the myriad vulnerabilities any system may have.
Thus, there is a multitude of possible attack vectors threatening your system. Sealing it with the use of kademlia goes a long way towards total security. But there are many other practices that should be used to defend against Hacking, Hijacking and System Penetration. We can only offer advice to be vigilant and aware of the size of the threat, and to take appropriate counter measures (and there are many measures to take). As noted elsewhere our use of client side encryption will assist, as will the frequent, programmed running of Backup operations (stored offline) and our ChubbyChecker. Insider jobs via Social Engineering techniques and third-party breaches are still high on the list of threats. Education of all staff can help here, as can monitoring of database access patterns, and vigilance (automated with AI) against abnormal patterns of use. Also, the use of Artificial Intelligence in this monitoring can make a difference when it comes to detection of “insider jobs”. An AI system can be trained to recognise excursions from normal usage patterns, and its performance is actually enhanced over time as it gains “experience”.
You could refer to the Absence of DNS page for further options.
—————————————————————————–
—————————————————————————–
Tx-Rails — Built by IT/OT Chain & Cloud Australia (ITOTCCA). Sydney · London.
The General™
India Research
भारतीय अनुसंधान
Elastos Carrier2: 
Lucis 
“
database.
