In such a scenario, the development prices, per consumer class, (in the example shown below, the Royal Flying Doctor Service, State District Health Services and State Health Supply Organisations) quoted in the table shown on The General page, would be reduced, since the different classes would often have nearly identical Applications to be developed, with only a relatively minor degree of variation between many of the Organisations. This would mean a development cost, per consumer class, of somewhat more than the price per member class, as quoted in that table (which is dependent upon the overall number of participating member classes in the entire Group), divided by the number of participating consumer classes under the IT Governance organisation. This represents a considerable saving on the General’s Table-Quoted development costs. The ongoing network supply and licensing prices would be the same, per consumer class, as quoted in that table.

Per Consumer Class Member (eg “State Health Service”, “State Supply Org”) $AUD		Initial Application Development $AUD Per Member-Class. One Member = One Business Channel with unique identity and ownership of data. 1 Year-Unit = “Project Resources and Superstructure”, (Human Resources provided by ITOTCCA following Garage Method), incl. 1-2 Build-Squad(s) per Site, for 1 Year [Prices herein assume 1 site per Member-Class, but are adjustable.]		Customer Support + Security: per Member-Class post Launch includes 9am-8pm (Sydney/London) Monthly (Mon-Sat) access to ongoing live/ticketed support Premium 24/7 Support available. Amount is split equally among members in class We pay a fee incurred by our “ChubbyChecker“ for security policing employing the Hedera Blockchain, which we pass directly to our customers. The Daily Total Fee (per Consumer Member Server) amounts to $US 0.0504 x (1002 [1000 for Pre-Registration + 1 for Post-Registration-execute + 1 for Post-Registration-commit/abort] x ultimate checks per day [eg 144] x 24 [Blocks per Ultimate Check]). for any installation. This total fee is divided equally among the member organisations on their servers. Usually, “installation” = “network”, but not always. Due to security requirements, aborted transactions count as transactions for the purposes of calculating fees. We will train Members’ IT Staff in supporting the system, and we provide an avenue for escalation to our Senior Customer Support Engineers for outstanding issues.		Monthly Network Lease Pymnt M-Chg(i) Ea. Consumer-Member post Launch Monthly Network Lease Pymnt As a startup in Medical, Commercial & Industrial Supply Networks we offer the incentive of Monthly Lease Payments on a Discounting rate. Our formula is determined by the total number of networked member classes on all our commercial networks. If this Total = Tm-c, then the Price per Consumer Class Member, Pm-c = $2.5k * (1 + 1/Tm-c). M_Chg(i) Ea. Consumer Class Member post Launch ($AUD)
1 MEMBER-Network being developed-for in current year		$465,000 * (5 + 3/M) = $ 3,720,000 per Year-Unit of Initial Devel/Member		$25,000 + Blockchain Fees Support/Security per Consumer Class Member or Member-Class		$5,000 per Total Consumer Class Members or Member-Classes across all networks
2 MEMBER-Network being developed-for in current year		$465,000 * (5 + 3/M) = $ 2,635,000 per Year-Unit of Initial Devel/Member		$25,000 + Blockchain Fees Support/Security per Consumer Class Member or Member-Class		3,750 per Total Consumer Class Members or Member-Classes across all networks
3 MEMBER-Network being developed-for in current year		$465,000 * (5 + 3/M) = $ 2,790,000 per Year-Unit of Initial Devel/Member		$25,000 + Blockchain Fees Support/Security per Consumer Class Member or Member-Class		$3,300 per Total Consumer Class Members or Member-Classes across all networks
4 MEMBER-Network being developed-for in current year		$465,000 * (5 + 3/M) = $ 2,673,750 per Year-Unit of Initial Devel/Member		$25,000 + Blockchain Fees Support/Security per Consumer Class Member or Member-Class		$3,125 per Total Consumer Class Members or Member-Classes across all networks
5 MEMBER-Network being developed-for in current year		$465,000 * (5 + 3/M) = $ 2,604,000 per Year-Unit of Initial Devel/Member		$25,000 + Blockchain Fees Support/Security per Consumer Class Member or Member-Class		$3,000 per Total Consumer Class Members or Member-Classes across all networks
6 MEMBER-Network being developed-for in current year		$465,000 * (5 + 3/M) = $ 2,557,500 per Year-Unit of Initial Devel/Member		$25,000 + Blockchain Fees Support/Security per Consumer Class Member or Member-Class		$2,900 per Total Consumer Class Members or Member-Classes across all networks
7 MEMBER-Network being developed-for in current year		$465,000 * (5 + 3/M) = $ 2,525,000 per Year-Unit of Initial Devel/Member		$25,000 + Blockchain Fees Support/Security per Consumer Class Member or Member-Class		$2,850 per Total Consumer Class Members or Member-Classes across all networks
8 MEMBER-Network being developed-for in current year		$465,000 * (5 + 3/M) = $ 2,500,000 per Year-Unit of Initial Devel/Member		$25,000 + Blockchain Fees Support/Security per Consumer Class Member or Member-Class		$2,800 per Total Consumer Class Members or Member-Classes across all networks
9 MEMBER-Network being developed-for in current year		$465,000 * (5 + 3/M) = $ 2,480,000 per Year-Unit of Initial Devel/Member		$25,000 + Blockchain Fees Support/Security per Consumer Class Member or Member-Class		$2,770 per Total Consumer Class Members or Member-Classes across all networks
10 Member-Classes – PER MEMBER CLASS in Network being developed-for in current year		$465,000 * (5 + 3/Mem-Classes)= $ 2,464,500.00 per Year-Unit of Initial Devel		$25,000 + Blockchain Fees Support/Security per Consumer Class Member or Member-Class		$2,750 per Total Consumer Class Members or Member-Classes across all networks
20 Member-Classes – PER MEMBER CLASS in Network being developed-for in current year		$465,000 * (5 + 3/Mem-Classes)= $ 2,394,750.00 per Year-Unit of Initial Devel		$25,000 + Blockchain Fees Support/Security per Consumer Class Member or Member-Class		$2,600 per Total Consumer Class Members or Member-Classes across all networks
30 Member-Classes – PER MEMBER CLASS in Network being developed-for in current year		$465,000 * (5 + 3/Mem-Classes)= $ 2,371,500 per Year-Unit of Initial Devel		$25,000 + Blockchain Fees Support/Security per Consumer Class Member or Member-Class		$2,580 per Total Consumer Class Members or Member-Classes across all networks
40 Member-Classes – PER MEMBER CLASS in Network being developed-for in current year		$465,000 * (5 + 3/Mem-Classes)= $ 2,360,000.00 per Year-Unit of Initial Devel		$25,000 + Blockchain Fees Support/Security per Consumer Class Member or Member-Class		$2,550 per Total Consumer Class Members or Member-Classes across all networks

 

From the above table, referring also to the sample screenshot below, there would be 3 Consumer Classes out of the total of all Member Classes (Personnel & Goods Supplier Classes, Government Consumer Classes [State Health Services and State/Federal Health Supply Organisations], the RFDS Independent Consumer Class, Independent Non-Consumer-Non-Supplier Classes), so the cost of initial development would amount to $AUD465,000 * (5 + 1/M) where M represents the number of participating Consumer Members (eg “State Health Services” and “State Health Supply Organisations”), with ongoing costs as shown in each row. It is difficult to show the various possibilities for combinations of Member-based Charging (eg The Medical) and Member-Class-based charging (eg The General), but basically network lease prices vary as the network is charged – whether that be by Member or by Member-Class. Ongoing prices are dependent only on the total of Members (The Medical) and Member-Classes (The General) combined. With regard to the Initial Development Prices, the relevant number of Members or Member Classes to refer to in the left-hand column, is defined by the number of Members (The Medical) or Classes (The General) in the Network being developed-for and in the year in which the initial development occurs. Thus, Initial Development costs are dependent on the numbers of Members/Member-Classes in each new Network.

We do not expect to usurp individual states’ rights, although, for our proprietary Ultimate Security System to function, we require the chosen Database to be a fully supported version of the Open Source database “PostgreSQL” (supported by Enterprise DB). PostgreSQL comes with no Licence Fees, representing an enormous saving, yet with the support of an experienced specialist PostgreSQL company in Enterprise DB, no increased risk is borne. In fact improved performance and security can be expected (99.999% Uptime). If Governments are not able to freely choose the required PostgreSQL option, we cannot pursue the matters further, and the value of improved security offered by our BFT-SMaRt/ChubbyChecker package must be foregone. Naturally, we provide a means of Machine-READ-ONLY interfacing to participants’ external accounting systems. We must maintain a boundary around our system to separate it from external systems. Of course our system will be fully auditable.

We urge Governments to consider seriously the value of a guarantee of Zero Fraud perpetrated from outside Organisation boundaries, since this is the full extent of our offer, and to contemplate the absolute absence of Database Licence Fees that accompanies the deal. We note here that we are prepared to donate our Design & Software free of charge to the RFDS. Also, to clarify, the Initial Development Price is a one-off cost, waived in the case of the RFDS.

Potential customers may refer to the base of the Bucordo Project Page for a comprehensive list of the phases undergone in a full database transaction Ordering and Replication Process (6 Phases), including an outline of the 29 detailed checks we perform to complete each cycle.

 

 

Please refer to the “Our Agreements” page for details of ITOTCCA’s “G.O.O.D” policy and our attitude to your data. In summary, we are “Hands Off” your data.

 

The Operational Technology Domain of Supply Chains encompasses many problems of Automatic Control and Monitoring as well as straightforward recording of sensor data output, possibly in co-ordination with other actuation devices or recorders. In some cases actuation of mechanical, chemical, pharmaceutical, electrical or electronic actions and flows is called for, with varying control/response times demanded. Some control problems need to be solved at “the Edge” – ie in the factory, or field (eg; when mobile, on road, rail and in the air) or theatre, or on the hospital/surgery floor, due to possibly very tight response periods required by some machinery (for example involving the use of Raspberry Pi, Industrial Pi, Arduino and equivalent computers). Others can be solved in the cloud, leaving IoT devices to control themselves with the localised assistance of Pi’s, PLC’s and other control devices. There is also a realm called “the Fog” level, lying between Cloud and Edge. Hybrid methods of solving Automatic Control problems are also possible.

ITOTCCA employs Mauringo’s Node-Red-Industrial, based on an IBM package written in NodeJS, for visualising, connecting and programming these automatic control elements. The package enables clear and safe viewing and interaction within a Supply Network’s Operational Domain. It is expected that Client Organisations will wish to be responsible for the control of their own IoT network devices. ITOTCCA undertakes to assist in the design of control networks and systems, and in the selection of fundamental control devices, but the responsibility for Full Design is a Cooperative undertaking, with mutual obligation, including the probable need to employ specialised contractors to some extent, in order to successfully achieve a properly controlled system. The pricing in this section (ie of Operational Domain Design) of overall work is determined by current rates for professionals in the fields of work at the time of design and implementation. ITOTCCA plays the role of Coordinator and Project Manager in this operational domain. All charges during development and implementation in the Operational Technology Domain (the “OT” in our “IT/OT”) are on an “at cost” basis, as with development and implementation in the IT domain.

 

 

 

ITOTCCA is currently in a phase of completing development of our Chubby Register/Chubby Checker “Zero Trust Enforcer”, with the code approaching completion, but with the necessary co-operation of the databases themselves incomplete, in as much as the PostgreSQL source code requires alteration, (as specified in the 2019 IBM article, which inspired our intention to achieve fully secured database networking, in the first place, but which lacked a complete security guarantee due to its reliance on Byzantine Fault Tolerance alone, which is defeatable, as detailed on the Bucordo Project page, and in the IBM article itself). This phase, though necessary, is beyond our in-house capacity, and we currently lack funding to outsource. As such we are not yet “market-ready”. We intend to achieve a working Proof of Concept before going to market, with which to find investors first, or to find interest from Supply Line markets at an initial stage.

 

 

From the Bucordo Project Page:

‘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 [currently] 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 where we now realise why homomorphic encryption is so attractive to some, in that the practice is targeted at enabling data analysis by “holders” of data such as Google and Microsoft,] 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 all fields not involved in 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 [the most confidential item needed, by far, to enforce data security, is the “amount” field in financial and other critical transactions, but this field is exposed alone, not with any other sensitive unencrypted 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).’

These large computer services corporations are effectively appropriating your data for their own gain.

 

 

Our imaginations are the only limiting factors in determining the possibilities for the use of secure Blockchain-backed Database/Datachain Networks, and automated IoT technology, in internetworked Supply Line Applications.

 

However, we can only say this ethically, if the Accountants, MBAs and other “monetisers” are kept out of the scene. You require Ethics to call yourself a Professional. These groups, too often, display a total absence of social ethics. Their Members seem to be taught to behave this way, and mutually reinforce their confidence in doing so. They can be rip-off merchants, and peddlers of the idea that these excesses of “Commercial Reality” should be accepted. Greed is NOT good.

 

We have a new dApp called The Medical, and it’s taking shape on Bitbucket. Here are 14 screenshots of the front end, as it exists so far. This Front End is intended to connect to a Backend, following the Bucordo design principles, which is also developing on Bitbucket, & is called “the-medical-backend”.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

With The Medical, and its associated “the-medical-backend”, we employ the concept of a User’s “Context”, which means every user has associated with them, their home State and District, or alternatively, a Federal- or State-wide responsibility level, or, for RFDS, their home Entity and Base, as appropriate. A user’s Context is established at Registration time (ie initially), but can be altered as necessary. Contexts simplify the development process as well as the User Experience. A User’s username is equivalent to their work email address. Any User will have at least one Role, however any number of simultaneous Roles is possible, with the approval of line management. Roles are created and deleted by sufficiently senior managers, as defined by ITOTCCA’s senior clients. At this point it is worth noting that due to the nature of our Datachain/Blockbase System, which is intended to mimic a real Blockchain, no database records are ever completely deleted. All details are retained in some form, indefinitely. Obviously this gives rise to a need to protect information in strict adherence to the Commonwealth Government’s 13 Principles of Information Privacy.

 

URL for IBM article

Please note there are 2 possible senses of the words Order and Orderer. One is intended to refer to the ordering of Health supplies. This is not the sense intended in the following paragraphs. The sense intended is the Ordering of Transactions – ie putting submitted transactions into an order determined by a consensus process on a virtual machine, and then committing or aborting them in that order. The order will appertain to each Virtual Machine independently.

An example of a Fully Developed National Database Network

The tableau shows an array of 22 Hardware On-Prem Canonical OpenStack Cloud Servers, positioned around the nation at State and Territory locations (minimum 8 in a fully developed network) and at Royal Flying Doctor Entity locations (minimum 7), in addition to a range of 7 Hardware Servers representing the 7 Supplier Classes.

These cloud servers are interconnected and designed to replicate all transactions faithfully across all
7×7 + 8×8 + 7×7 nodes (162 nodes).

The extended diagram below gives an indication of the nature of replicating from each client’s requests, across all networked nodes, using a single client as an example. Each client submits transactions to their own V.M./load balancer which is multicasting each transaction to all other V.M’s in the entire national network (ie to the other 22 – 1 = 21 load balancers). Each load balancer is programmed to be aware of its own expected local client id’s from the range of clients “belonging to” that load balancer. Transactions from these clients are multicast across the network, as well as participating in their local round robin process. When a load balancer receives a transaction request from an “external” client, (ie not on the list of local clients “belonging to” that load balancer/V.M.), it distributes this request to an inernal node, (determined by the current position in the round robin process for that load balancer), on its V.M., without further multicasting the request.

Whilst the various load balancers are engaged in a round robin process of distributing transactions upon receipt to one single node in its own V.M., and, for “local” requests only, multicasting to the remaining V.M.’s across the national network, it is the BFT-SMaRt ordering and replicating packages (ie ‘the orderer nodes’) which multiply (replicate) the transactions received on each node, across all nodes in a V.M., each holding the status of a Master Copy, and order the full set, defined in terms of Blocks, before executing then committing/rolling-back the transactions in the Block. The size of the Blocks (currently 1000 transactions) is determined by software written by ITOTCCA, as is the number of Block Commitments (currently 24) in an Ultimate Checking phase involving ChubbyChecker.

Our Virtual Machines

 

 

 

 

A different perspective is provided by the Social Housing, Real Estate and Construction Industries

 

 

One obvious question is “Will the variety of 22 (or 42 in the Construction Supply case) Virtual Machines all replicate their received transactions in the same order?” The answer is that, due to the independence of each V.M., and the asynchronicity of the system, their orderings will be different. However, we look after these discrepancies after every 24th Slab is checked by examining the 24 processed Slabs (multiplied by the number of each Enterprise’s Network-wide clusters) to extract the transactions which have been processed differently between clusters. There are several possible important differences:

• A transaction may have been rolled back in one or more clusters without evidence of reprocessing and committing successfully in some of those clusters. As long as there is at least one other cluster which committed this transaction successfully, the transaction is forcefully committed in all exceptional clusters
• A transaction may be omitted in one or several clusters (ie not executed) despite being executed AND committed in at least one other cluster. These transactions are force-replayed (ie executed, if necessary repeatedly, until successfully committed). The events where all the other clusters involved have executed but not committed a transaction, are not acted upon
• Variations between clusters in the order of transaction execution, when followed by commitment, can not give rise to anomalies. ITOTCCA follows IBM’s use of the concept of SSI (Serialisable Snapshot Isolation) and the associated methods, to assure database consistency, which we employ to ensure consistency during Block commitment procedures. This involves the related notions of keeping lists of “In Conflict” and “Out Conflict” transactions, and of “near” and “far” conflicts, and the associated rules using these definitions. You may refer to this page for expositions.
  Finally, we observe that if every virtual machine is kept internally and externally consistent, then the entire network is also internally and externally consistent, despite variations in the order of committed transactions, and, with the latter synchronised 24-Slab examination, even including the possibility that different transactions may be rolled-back on the databases of different virtual machines. The independent internal and external consistency of the various machines’ databases is still a guarantee against non-insider fraud, noting that ITOTCCA never would be able to offer guarantees against “insider jobs”, even for only one stand-alone virtual machine, if we class “insiders” as any person granted permission to register with the Elastos DID system, and authorised to submit any particular class of transactions, and therefore able to sign those transactions. The guarantee is qualified by the fact that we process each Critical Transaction individually (where our clients define “Critical” Tables), but we only perform Batch Processing of transactions classified as “Non-Critical”, in order to balance performance and cost against residual risk.

ChubbyChecker thus ensures the integrity of the states of all databases in the network at the end of each 24 Block Commitments, as determined independently by each virtual machine (meaning there would be up to 22 different transaction-orderings and 22 different points at which 24 Block commitments will have elapsed).

1. By performing a full set of 29 internal consistency cross-checks to verify consistency across nodes in a virtual machine, and also,
2. By performing, at the same stage, a comparison of final database states, with intercepted Transaction Traces, stemming originally from the receipt of requests directly from clients (including clients at other locations) at the load balancers, before these requests enter the ordering, repication, execution and commitment/rolling-back system. The latter Traces are recorded on Redis in-memory key-value stores and on Etcd dataStores, transaction-by-transaction, across all V.M.’s/load balancers, and constitute a guaranteed audit trail, providing a means of checking for external consistency of the database state, at this Ultimate Checking stage.

Thus there are 22 (= number of V.M.’s in the network) possible independent origins of Alarms indicating faults, in this representation of a fully developed National Network. Also, the network is extensible, due to the independence of the V.M’s, and need not encompass 22 Hardware servers from the beginning. It is possible to view the independence of V.M.’s, therefore, as an advantage of the design. BFT-SMaRt allows for this extensibility (under the heading “Reconfiguration”) in its own design.

One of the significant advantages of these processes, including the use of our ChubbyChecker with the Byzantine Fault Tolerant process provided by BFT-SMaRt, together with the use of client-side encryption, Role Based Access Control (RBAC), and the offer of asymmetric cryptography where legitimate and agreed, is that business partners, in this case, Governments in partnership with their suppliers, do not need to trust each other in order to gain the benefits of participation in automated and secure trading including full accounting. For the same matter, neither do Federal, State and Territory Governments need to trust in each other, nor do suppliers need to trust other suppliers.

On the subject of accounting, as far as accounts pertaining to Health Supply purchasing and related items are affected, we must insist that Government Health Departments be prepared to cross-over to our proprietary Accounting System, the multiplexed ‘Block ‘n’ Tackle’, which allows for multi-party transactions. We cannnot allow other than machinic read-only interfaces to our system, for security reasons. This means both the consumers (Health Departments and RFDS Entities) and the business suppliers in the system, are required to participate in accounting systems provided by ITOTCCA’s Block ‘n’ Tackle, for transactions concerning this Health Supply Network. The interfacing of our system to Governments’ and Business’ broader systems must be on a machine-read-only basis. At this point it is worth remembering that Governments and businesses hold their own encryption keys to their own data. We also refer you to our “G.O.O.D.” Agreement.

Our Block ‘n’ Tackle accounting system will be open for thorough testing before going ino production. We have completed the skeleton structure and functioning of the system, in the form of “update_master()” and “update_tax()” functions in PlpgSQL (the Postgres procedural language) and tested and proven these using Java client-functions. The details of the fields for the Journals and Ledgers must be completed during contracted development.

The networking of databases also enables the sharing of information aside from the operation of Smart Contracts for trading in goods. The way is open, with the replication of information across databases and the availability of asymmetric cryptography, to temporarily grant permission, say, for an entity of the RFDS to access patient information, legally, by simply encrypting the necessary data with the public key of the receiving entity, and sharing the data with the RFDS (via the secure Carrier2 Peer to Peer Elastos Business Network – avoiding insecure email transfers). The convenience and security of the total replication system, provides a way for the RFDS, in this case, to access external data, legally, on their own servers.

Obviously this also means that information may be shared, when legally permissible, via the same means of asymmetric cryptography, between State Health Departments and RFDS entities alike. A similar process would occur for the shared data involved in Smart Contracts for the supply of Goods and Services. The advantage of using databases instead of blockchains like Ethereum, lies partly in the volumes of data that can be handled on databases, as well as lying in the non-public nature of such database networks, in comparison to blockchains.

As stated elsewhere on this page, we are prepared to donate all these software-based services to the Royal Flying Doctor Service, as a full participant.

So, with regard to the integration of Carrier 2 with BFT-SMaRt, we first need an extant SuperNode Network (Bootstrapping Nodes), and a committed process for any node requesting to be bootstrapped onto an authorised Network, in response procedures on the SuperNodes (such as those involved in the BootstrapCommand class). The request process on the Database Nodes must exist also.

 

 

Executive Summary

Summarising, what you get is a system that enables automated trading using Smart Contracts that are enacted on a private network, using asymmetric encryption procedures, and also due to all database clusters acting as Masters in replication procedures, a partner organisation can access the revocably-shared data on their own local server.

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.

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 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 Elastos Carrier2, 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 allow 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 that 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 a 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 Carrier2 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 this is simply not a problem. Note that the backups need to be kept offline and thus inaccessible to an infiltrator online. 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 Carrier2 goes a long way towards total security. But there are many other practices that should be used to defend against Hacking 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 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) of 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”.