BFT/DHT Bucorde security worthy of Air Commodores

________________________________________________________________________

general enterprise accounting‘BFT/DHT Bucorde’™general enterprise accounting

Twinned Networks

An Absence of DNS (ADNS) Enterprise System

Bucordo/BFT-SMaRt
Database and Server Nodes


In the DataCentres

[Supernodes, Secondary Nodes]

twinNetworks

Kademlia/jvm-libp2p/DHT
Distributed Hash Table Nodes


Global

[Supernodes, Secondary Nodes,
Tertiary (Client) Nodes]

VS

Blockchain

With ChubbyChecker
And SuperChecker

Ultimate Transaction
Cross-Checking

ChubbyChecker
ChubbyChecker“.

QUIC/gRPC
HTTP3
Transport
Layer

Peer Discovery
by NodeId

TLS 1.3
Transport
Encryption

Total Absence
of DNS
~ ADNS ~

________________________________________________________________________

Merging adapted jvm-libp2p SuperNodes
with Bucordo PostGIS Database Nodes
Anchored to Blockchain

© by IT/OT Chain & Cloud Australia Pty Ltd 2022-2025

You might call it ‘100% FAULT INTOLERANCE for Databases’
(with In-Transit Security)

________________________________________________________________________

We get a first-pass level of security with BFT-SMaRt, which we strengthen using a “twinned network” in the form of an enhanced Carrier2 DHT Network overlaid on the BFT Network of Enterprise Databases (Secondary Nodes), with each Enterprise Network headed by one Carrier supernode per Business Network. All Carrier Supernodes participate in a separate Cluster-Network of Supernodes, where the metadata on this sub-net is also ordered and replicated by BFT-SMaRt. The network of supernodes controls the recording
of transaction trace metadata for the networks’ ChubbyCheckers, and is itself checked by SuperChecker, the top-level Checker.Supernodes play a role of interconnection between Wide Area separate clusters any time it is desirable to provide communication between these clusters and they are parts of a unified Enterprise Network. This enables intersite collaboration. All secondary node networks and the supernode network, record, and sequentially compare, their own Merkle Roots on Elastos.
ITOTCCA can provide Blockchain-networked Secure Database Access systems on the Elastos Smart Web, which largely automate intra-network trading and leave Banking, Email and and other traditional webservices to the traditional applications. However, at negotiable rates, we can advise on and implement government- and/or vendor-agreement-backed interfaces or workaround methods to save data in files, from Emails, Bank Statements and other traditional Web Services for validated reading into our ultra-secure systems, all initiated by you.
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 Elastos, amounts to a list of 20 data fields as follows:
  1. Enterprise Number (entnum – Unique 64-bit Integer)
  2. MemberOrClass Id (memberOrClassId – 28-bit byte array for the network’s members/member classes)
  3. Key (recordId – Unique 100-bit byte array)
  4. TransactionId (txId – UUID String)
  5. BusinessNetwork (network – 28-bit byte array)
  6. InstallationOrVM (installation – Big Integer)
  7. Database (database – 98-bit byte array)
  8. Schema (schema – 100-bit byte array)
  9. Table (table – 100-bit byte array.)
  10. Entire Tx Trace Hash (hash – 64-Byte Array (Merkle Leaf))
  11. ClientId (clientId – Unique 44 character Base 58 array plus first 16 characters = ’09-0000000-0000000′. 60 characters sha3-512 hashed.)
  12. TxSignStr (txSignStr – String)
  13. BlockId (blockId – UUID String)
  14. SlabId (slabId – Big Integer)
  15. BlockHeight (blockHeight Small Integer)
  16. Amounts (int64Amounts – List of Big Integers [JSONB])
  17. Exponents (int32Exponents – List of Integers [JSONB])
  18. OpCodeExec (opCodeExec – Boolean)
  19. OpCodeCommit (opCodeCommit – Boolean)
  20. MerkleRootHex (merkleRootHex) – Hexadecimal String)

Each Enterprise Transaction produces these 20 fields of Transaction Trace Metadata, multiplied by 1024 transactions per block per network then by 24 blocks per slab per network.
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.
  • Data involved in Systems Management.
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.
  • Operations involved in systems management.

 

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.

Our system employs arrays of client-facing tables (with Table.System.oid mapping to UseCase.Id) corresponding to transaction use cases. Their data fields are designed to collect all client form-data followed by procedures involving trigger functions that process the data and store it in the Enterprise/Accounting-Structured parts of the databases. As such, one transaction will give rise to multiple records and record Ids, aside from the Record Id (RecordIdprelim) created in the original data-receiving table. All Enterprise databases/schemas have 2 sections 1. Class ‘A’ tables: Enterprise/Accounting section, and 2. Class ‘U’ tables: Use Case section. The Use Case Section is triggered to process and distribute data into the Accounting Section. In addition there are the DHT-connected Metadata Database and Storage Systems (PostGis on Supernodes with etcd medium-term persistence on the Secondary Nodes).

The following table is a summary of our 512-bit (Class ‘A’), 512-bit (Class ‘UR’), 362-bit (Class ‘U’) and special Base 58 encoded (an exception, with 44 Base58-encoded digits representing submitted Elastos Client DIDs) key systems (8 leftmost bits to signify Key Type, 28 bits for enterprise network enumeration, followed by 28 bits reserved for Member Class enumeration (when used), which are followed by unique 448-bit, or 298-bit Suffix sequences). Client Ids, as noted, represent an exception to these rules.
sha3-512 and reduced Key divisions:

1. KeyType=000000002 Peer/Node.Id
(Supernodes).
Node Identifier Suffix: 448 bits:
Unique identifier.
Full key prefix in Hex:
0x00-NNNNNNN-MMMMMMM
2. KeyType=000000012 Peer/Node.Id
(Secondary nodes).
Node Identifier Suffix: 448 bits:
Unique identifier.
Full key prefix in Hex:
0x01-NNNNNNN-MMMMMMM
3. KeyType=000000102 Peer/Node.Id
(Tertiary nodes).
Node Identifier Suffix: 448 bits:
Unique identifier.
Full key prefix in Hex:
0x02-NNNNNNN-MMMMMMM
4. KeyType=000000112 BFT-Database.Id
[including main Enterprise
Accounting Datatable Structure.]
Identifier Suffix: 98 bits:
Unique general database identifier.
Full key prefix in Hex:
0x03-NNNNNNN-MMMMMMM
5. KeyType=000001002 BFT-Schema.Id
[including main Enterprise
Accounting Datatable Structure.]
Identifier Suffix: 100 bits:
Unique general schema identifier.
Full key prefix in Hex:
0x04-NNNNNNN-MMMMMMM
6. KeyType=000001012 BFT-Class ‘A’
BFT-Table.Id

[including main Enterprise
Accounting Datatable Structure.]
Identifier Suffix: 100 bits:
Unique identifier.
Full key prefix in Hex:
0x05-NNNNNNN-MMMMMMM
7. KeyType=000001102 BFT-Class ‘A’
BFT-Record.Id

[including main Enterprise
Accounting Datatable Structure.]
Identifier Suffix: 150 bits:
Unique identifier.
Full key prefix in Hex:
0x06-NNNNNNN-MMMMMMM
8. KeyType=00001112 BFT-Class ‘U’
Database.Schema.Table
Corresponding to:
DHT-Database.
(public)Schema.Table.Record
for DHT_TX_Builder.
(Full Suffix: 298 bits)
BFT-Table.Identifier (Trailing 100 bits)
of BFT Class ‘U’ table:
Identifies the enterprise database table: corresponding,
in addition, to Metadata Record Identifier
for Transaction-Builder
Record.Id (100 bits)
in DHT System.
The Full 298-bit key-suffix of the
user’s target client-facing
data-receiving Table in
BFT segment is used to
convert that BFT Table Id,
by prepending “000010002“,
to DHT-table-key suffixes
with leading Network
and MemberOrClass Ids
in the DHT system’s
Transaction Builder databases,
thus converting a Class ‘U’
BFT-system Table Id to a
Class ‘U’ DHT-system Record
Id, of the form DHT-Database.(publicSchema).Table.
Record Id, giving the key to
the required “Build Metadata” in the DHT System
for the current Request.]
Full key prefix in Hex:
0x07-NNNNNNN-MMMMMMM
9. KeyType=000010002 BFT Class ‘UR’
Tx Trace Metadata Source


(Suffix: 448 bits)
Table.Identifier (100 bits):
Identifies the Tx-Trace metadata table.
Full key prefix in Hex: 0x08-NNNNNNN-MMMMMMM
10. KeyType=000010012 BFT-Class ‘UR’: BFT Enterprise Database.Id
(Suffix: 448 bits)
Associated, as Source Transactions,
with Transaction Trace Metadata
(DHT Class ‘UR’ Database)
Record.Identifier (100 bits): Identifies the record. Full key prefix in Hex:
0x09-NNNNNNN-MMMMMMM
11. KeyType=000010102 DHT-Class ‘UR’: DHT Enterprise Database.Id
(Suffix: 448 bits)
Associated, with Source Transactions,
ie Transaction Trace Metadata
(DHT Class ‘UR’ Database)
Table.Identifier (100 bits): Identifies the table. Full key prefix in Hex:
0x0A-NNNNNNN-MMMMMMM
12. KeyType=000010112 DHT Class ‘UR’ Database.Schema.
Table.Record.Id:
(Suffix: 448 bits)
Record.Identifier (150 bits): Identifies the record.
Associated with BFT-Class ‘UR’:
BFT Enterprise Database.
This is the Transaction Trace
Storage System.
Full key prefix in Hex:
0x0B-NNNNNNN-MMMMMMM
13. KeyType=000011002 DHT Class ‘U’ Database.Schema.
Table.Record.Id:
(Suffix: 448 bits)
Table.Identifier (100 bits): Identifies the record.
Associated with BFT-Class ‘U’:
BFT Enterprise Database.
This is the Transaction Builder
Storage System.
Full key prefix in Hex:
0x0C-NNNNNNN-MMMMMMM
14. KeyType=000011012 DHT Class ‘U’ Database.Schema.
Table.Record.Id:
((Suffix: 448 bits)
Globally unique identifier for a record. Full key prefix in Hex:
0x0D-NNNNNNN-MMMMMMM
15. KeyType=000011102 Role.Id
(Suffix: 448 bits)
Globally unique identifier for a Role. Full key prefix in Hex:
0x0E-NNNNNNN-MMMMMMM
16. KeyType=000011112 Client.Id
Personal Identifier
(Suffix: 448 bits)
Globally unique identifier
for a client (personal).
Sha3-512 hash of client’s
Elastos DID with
Prefix (Hex) replacing
first 16 hashed hex digits.
Full key prefix in Hex:
0x0F-0000000-0000000
17. KeyType=000100002 Value Identifier
(Suffix: 448 bits)
Unique identifier for DHT values. Full key prefix in Hex:
0x10-NNNNNNN-MMMMMMM
18. KeyType=000100012 FULL_CLASS_A_KEY
(Suffix: 448 bits)
512-bit Key (Database + Schema + Table + Record) =
(fullTableName.Record).Id =
Db.Sch.Tab.Record
Full key prefix in Hex:
0x11-NNNNNNN-MMMMMMM
19. KeyType=000100102 FULL_BFT-CLASS_U_KEY
(Suffix: 298 bits)
362-bit Key (Database + Schema + Table) =
(fullTableName).Id =
(Db.Sch.Tab).Id
Full key prefix in Hex:
0x12-NNNNNNN-MMMMMMM
20. KeyType=000100112 FULL_DHT-CLASS_U_KEY
(Suffix: 298 bits)
362-bit Key
Db = {BFT-CLASS_U-DatabaseId}
+ Sch = default {Public-SchemaId (nulled)}
+ Tab = {BFT-CLASS_U-SchemaId}
+ Rec = {BFT-CLASS_U-TableId}
Full key prefix in Hex:
0x13-NNNNNNN-MMMMMMM
21. KeyType=000101002 FULL_BFT-CLASS_UR_KEY
(Suffix: 448 bits)
512-bit Key (Database + Schema + Table + Record) =
(fullTableName.Record).Id =
Db.Sch.Tab.Record
Full key prefix in Hex:
0x14-NNNNNNN-MMMMMMM
22. KeyType=000101012 FULL_DHT-CLASS_UR_KEY
(Suffix: 448 bits)
512-bit Key (Database + Schema + Table + Record) =
(fullTableName.Record).Id =
Db.Sch.Tab.Record
Full key prefix in Hex:
0x15-NNNNNNN-MMMMMMM

In the Prefix portions to the left, “0xKK-NNNNNNN-MMMMMMM” stands for the 7-digit Enterprise Network Id in Hexadecimal Notation (NNNNNNN), (allowing for ~ 67 million networks), followed by 7 hex digits representing the Member Classes and/or Members in a Network (MMMMMMM) [where relevant and used – otherwise = 0000000]. The first 2 digits, KK, in the prefix (currently 0 – 22 in decimal order or 0 – 15 in hex), stand for the Key Types.

Thus, where there are 448 bit-systems (112 Hexadecimal digits), given in bits by 448 = 512 – 64 (64 = 8 + 28 + 28) [in Hex digits: 112 = 128 – 16 (16 = 2 + 7 + 7); in Bytes: 56 = 64 – 8 (8 = 1 + 3.5 + 3.5)], these enumerate all the Nodes, Databases, Schemas, Tables, Metadata Databases and Table types, Classes ‘A’ & ‘UR’ Records, Users and DHT “Values” for every Network and Member/Member-Class-within-Networks.

And, as there are 298 bits for Class U types, (75 Hexadecimal digits), given in bits by 298 = 512 – 214 (214 = 8 + 28 + 28 + 150 [so that the Class ‘U’ crossover schema fits]) [in Hex digits: 75 = 128 – 53 (53 = 2 + 7 + 7 + 37); in Bytes: 38 = 64 – 26 (26 = 1 + 3.5 + 3.5 + 18)], these enumerate all the Class U Databases, Schemas, Tables, DHT-(Metadata) Databases and Table types and DHT-Class ‘U’ Records for every Network and Member/Member-Class-within-Networks.

The minimum spanning spaces are given:

  • for Databases = 98 bits = to represent 3.17 x 1029 databases
  • for Schemas = 100 bits = to represent 1.26 x 1030 schemas
  • for Tables = 100 bits = to represent 1.26 x 1030 tables
  • for Class ‘A’ Records = 150 bits = to represent 1.43 x 1045 records
  • for Class ‘UR’ Records = 150 bits = to represent 1.43 x 1045 records
  • for Class ‘U’ Records = 100 bits = to represent 1.26 x 1030 records
  • John_L_Olsen 

    πάντα πιστός.

    Always faithful.

    In order to accomplish this, we recognise that the Class ‘U’ System must operate with a normal Prefix (64 bits) but a Suffix shortened by 150 to equal 298 bits. This is to enable the crossover public-schema-system, for Tx-Builder Metadata, to fit the structure we create, enabling the Id of the Client-facing BFT-System Class ‘U’ Table to give the Id needed for the corresponding DHT Class ‘U’ Record. The Class ‘U’ Record has the same suffix as the BFT Class-‘U’ Table (which is a Client-facing data form receiver). The Table Id is also mapped to the list of Use Cases for the Enterprise Network. The DHT Record Id gives access to the required Transaction-Builder Metadata, enabling appropriate construction of Prepared Statements for the Use Case Query under request.

    The BFT- and DHT-Class-‘UR’ Systems represent keys whose suffixes correspond, thus tying together records in the arrays of Client-facing BFT Enterprise data-receiving tables with records storing the Transaction Traces of the former records. Investigations and Auditing are thereby enhanced.