Blockchain Fintech – Chander Govindarajan, Praveen Jayachandran, Senthilnathan Natarajan, Balaji Viswanathan, International Business Machines Corp

Abstract for “Distributed blockchain database with blockchain attributes”

An example operation could include one or more processors that receive a command from a client, which may contain a database function and parameters, and execute the command on the database data. The interface can also transmit the command to other databases within a decentralized system where each database node is managed by a different entity. In response to receiving a request by an ordering node, the processor may store information about the command in an appendable immutable log.

Background for “Distributed blockchain database with blockchain attributes”

A blockchain can be used to store transactional data regarding the exchange or goods of assets (e.g. monetary, goods, etc.). When certain conditions are met, asset-based exchanges can be executed within a blockchain. The transaction results are stored in a Blockchain ledger that is replicated across multiple blockchain nodes. This information can be provided by any entity or individual to a public blockchain. It should be checked and verified. This is called consensus. A blockchain system relies on a consensus, which transfers authority and trust to a network. It allows its peers (i.e., Blockchain peers) to record transactions in a public “block” and create a unique ‘chain. A blockchain is also known as. A blockchain uses cryptography via hash codes to authenticate a transaction source. This eliminates the need for any central intermediary.

A distributed database system is one in which different storage devices are controlled by the same processor. The distributed database system could be located in different locations in the same physical area or spread over multiple computers. Distributed databases can store data on multiple computers. This allows transactions to be processed by many machines instead of just one. The distributed database uses duplication to ensure that all databases are up-to-date. The system first identifies a master database and then copies the contents to the slave databases. The process of duplication is usually completed within a specified time frame. This is done to ensure that all locations have the same data. Users can only modify the master database during the duplication process. This protects local data from being overwritten. The master database node in the above master-slave distributed data base architecture is trusted by all slaves as a single entity that owns/controls the system. In multi-master distributed databases architectures, all masters trust each other’s data as a single entity own/control the systems. In contrast, in our proposed decentralized system architecture for database systems, each database node is controlled/owned by a different entity. One entity can not trust another entity.

“In one embodiment, there is a computing device that includes one or several processors that can receive a database command form a client system. The database command may include a function and parameters that will be used by the function to execute the database commands on database data. An interface that transmits the database command to other databases within a decentralized system is also provided. The processor may also be configured to receive a request from an ordering point of the decentralized system to execute the database command and to store information about it in an appendable immutable log.

“Another example embodiment provides a method that includes one of two things: receiving, from a processing device a database commands from a client systems, the database commands comprising a function to be used by that function, executing that database command on the database data, transmitting, via an interface, the received command to one or several other databases that are part of a decentralized system of database systems, and, in response to receiving a request form an ordering node of that decentralized system, committing the results of the log.

“Another example embodiment provides a non-transitory computer-readable medium that contains program instructions. These instructions, when executed, cause a computer’s to receive a database command from client systems. The database command comprises a function and parameters that can be used by that function. It also transmits, via an interface, the database commands to other databases within a decentralized system. In response to an order from an ordering node, the processing device commits the results of execution to a data store. Information about the command is stored in an append-only database log.

“Other features or modifications may be apparent in the following description when taken together with the drawings, and the claims.”

It will be apparent that components of the present invention, as described and illustrated in the figure herein, can be arranged in many different ways. The following description of at least one embodiment of a method or apparatus, non-transitory computer-readable medium, and system as illustrated in the attached figures is not intended as limiting the scope of this application. It is only representative of some embodiments.

“The features, structure, and characteristics described in this specification can be combined in any way that is appropriate throughout the embodiments. The use of phrases like?example embodiments’,?some embodiments?”, or similar language throughout this specification indicates that a particular feature or structure described in connection to an embodiment could be included in at least one embodiment. It is not to be taken to mean that it is omitted from any other embodiments. The phrases “example embodiments”, “in some embodiments,” or “in other embodiments” or similar terms may refer to the same group. Furthermore, the features, structures, and characteristics described may be combined in any way in one or more embodiments.

“In addition, the term’message’ may be used in the description of embodiments. While the term?message? may be used to describe embodiments, the application can be applied to any type of network data such as packet, frame, or datagram. The term “message” is used here. The term?message? or?request’ can be used interchangeably. or?request? may contain packet, frame, datagram and any equivalents thereof. While certain types of signals and messages may be shown in certain embodiments, they are not limited by a particular type of message or signaling request. The application, however, is not restricted to a specific type of signaling.

“Instagram” refers to a distributed database system. In another embodiment, it refers to a distributed database computing system. It may contain blockchain attributes that increase the security and storage of the database, while still allowing the database to process rich transactional queries (e.g. SQL, DML and DDL). The blockchain system can be a complex architecture and consume excessive resources. A blockchain system can be too complex for some use cases. These examples show a decentralized database system which can incrementally implement the blockchain attributes. Each attribute can also be turned on/off in the system by changing a single setting. A user can set the number of supported blockchain attributes in the database.

There are many similarities between a database and a blockchain system. Smart contracts are similar to stored procedures in a database system. A blockchain system also permits access control that is based on roles, grants, and row-level security policies. There are important differences between a blockchain and a database. A blockchain system, for example, requires that developers create smart contracts in specific programming languages. An application, even if blockchain properties are available within a database can still be written in the same way as any other database. However, it may also have additional properties that are similar to a Blockchain system. A developer does not have to learn a new programming language. The database described in this article allows easy migration of existing applications, while leveraging blockchain capabilities and interfacing with similar systems within other organizations for business.

“Another difference with blockchain systems is that they do not support rich queries or complex joins of multiple pieces information. Blockchain properties can be supported within a database to allow rich query and transactional processing support (e.g. support for SQL queries and DML, DDL, and DML). These examples improve query and transaction performance by allowing everything to be handled in a single database. This is unlike a blockchain system that has many components built on top of the database (often duplicateing what is already being done within the database). Although relational and nonrelational databases can be used, certain elements like transactions and atomic operations may not exist in non-relational implementations. The database may perform the traditional functions, though in a modified way, such as inserting/updating/deleting elements, querying at various levels of complexity (using SQL in case of relational database), etc.”

“Another difference in distributed databases is that data replicas between the nodes of a database system, such as master-slave or multi-master database systems, may be trusted?. A distributed database node can send a message to another. The second node will trust the first node about the content and origin of the message. This assumption may be broken according to different embodiments. A notion of security amongst database replicas may then be implemented while taking advantage of existing replication capabilities within the data base. A trusted distributed database system that is owned by one entity can become a decentralized database system, where each databased node may be owned by another entity. The decentralized database system may include a notion of consensus and total order of transactions. This is to ensure that all databases nodes commit transactions in the exact same order, regardless of the order in which they are executed. A complete log of all transactions can also be maintained across all nodes. These concepts are not possible in a traditional distributed database.

Another aspect of the examples is that these properties can be implemented within a decentralized data base. The properties can also be configured incrementally using settings in a configuration file. If an application requires?immutability?, it can be set up to support that property without the need for multiple database nodes, complex cryptography, or even a total order among transactions. By popular definition, a blockchain system cannot exist without cryptographic security. The core property of decentralized trust is the cryptographic security.

“FIG. “FIG. Referring to FIG. Referring to FIG. One or more nodes may be included in the decentralized database 110. To ensure that transactions are ordered in a multi-node system, the decentralized database system 110 includes an ordering node (116). The database computing systems 112 can be connected directly to one another (e.g. via a USB interface). Or, they may be connected to each other via a network 112, such as via a USB interface. According to different embodiments, the decentralized system 110 can be used for execution and recording database queries. These database queries may be used in order to select, update, or interact with data stored within the data stores of decentralized system 110. For example, client systems 120 (e.g., computers, tablets, mobile devices, POS terminals, software applications, etc.) The client systems 120 may communicate with nodes 112 over a network like the Internet or a private network and send database commands to the database.

The ordering node 116 and the database node 112 may be databases servers that store and manage access to data. The individual nodes can be controlled by different controlling entities in this situation. All nodes 112 may have a complete replication of the database data. Each node 112 may have a copy of each database table, function, and so forth. However, this replication can be set up. After a protocol configuration in the system, nodes can interact with each other. The nodes 112 and 113 may communicate new transactions with one another, and each node can execute each transaction and receive the results. Other interactions can also be made between nodes, such as discovery and block transfer.

“Accordingly to different embodiments, the decentralized data base system 110 could implement multiple blockchain properties. The system 110 may include the following features:

These blockchain attributes can be enabled/disabled through a database configuration file, which is incorporated into the database computing system 112. The configuration file can add the following configurable Blockchain properties to the database. It can either be true/false, or it may take a name:

“IMMUTABLE=true/false”

“TAMPER_PROOF_ORDERER=true/false”

“TAMPER_PROOF_TOTALLY_ORDERED=true/false”

“ORDERING_TRUST_MODEL=Practical Byzantine Fault Tolerance (PBFT)”

“NON_REPUDIABILITY=true/false”

“Immutability and append-only transactions are database transactions that are added to and modified to existing data. Traditional database systems give more importance to data, while long-term only the actual data values are considered. Data is not appended to an immutable database. This ensures that the entire history and commands used to manipulate or access the data are preserved. Append-only transactions means that the transaction records are given to individual transactions. These transactions cannot be altered.

“To attain this blockchain attribute within database 110, a?ledger?” A?ledger, which is a table in the database system that can be used to store transaction logs for both committed and aborted transactions, may be implemented. A transaction log entry can be made during COMMIT/ABORT. The?ledger is not permitted to host database commands like insert, update, or delete. Administrators or users cannot execute database commands on the?ledger. You may instead be restricted to using the COMMIT/ABORT functions to enter transactions log entries. The above actions can be enabled by user/admin when they enable immutable Blockchain property. The database system will not create or manage a ‘ledger’ if it isn’t enabled. System table to keep immutable transaction logs.”

A hash-chained, totally ordered log of transactions is a method of protecting entries by hashing each entry. A classic log of transactions, such as A, B and C, is not tamperproof because later A could be replaced by D, or the order changed (such B, A, C). A hash-chained, totally ordered log looks more like this:

“Where each entry in the log contains a reference to the previous entry, and so forth. This database log can be maintained at multiple database nodes in a decentralized system. It provides an audit trail of transactions as each entry can be signed and timestamped. The transaction may be stored on?ledger instead of being just stored there. Instead of storing the transaction on?ledger, you can link them using hash chains. The transactions will then be stored onto?ledger. table in the order of the database node COMMIT/ABORT. This property indicates the order in which transactions are committed/aborted.

“There is also the option of ‘totally? An ordered log of transactions. When multiple database nodes participate in the decentralized system, the totally ordered blockchain property can be enabled. This blockchain property is important because transactions can be submitted to different databases nodes in different order. It ensures that all the database nodes are committing/aborting transactions in the same order. The?ledger? will have the same order of transactions. The?ledger? system table will contain the same ordered chain of transactions that are committed and aborted. The ordering service (e.g. ordering node 116) is capable of performing either trusted central ordering or trusted consensus based ordering to ensure that all nodes have the same order.

To control access to the database system, a membership service management system could be used. This module can authenticate and authorize all parties to interact with the system. This property can be described as non-repudiation. One party P cannot perform an action A, but later claim that they didn’t. Because the system can prove occurrence of all actions/interactions, then non-repudiation is guaranteed. Transactions signed may include transactions (the primary method of interfacing with the system). These transactions are cryptographically signed under the control of the membership service management software. Databases have traditionally provided roles and permissions that were associated with them. Non-repudiation can be achieved by using a membership management system embedded in the database. Signatures are used to control interaction. A query processor engine at the database node may include a cryptography module that verifies that the transaction has been signed by the correct entity. This is called non-repudiation. The transaction may be rejected by the database node. The?ledger table also contains the signature. The database node may also add the signature that was added to the transaction by the submitting entity.”

“Transactions, in this context, can be written as a stored procedure and are the only way to interact the system. Every transaction logic can be written in a stored procedure that is agreed upon by all parties to the blockchain network. Transactions can be used to create or update tables, modify rows, delete data, or query specific patterns. The system might restrict the access of different parties to certain resources/data. This feature is provided by the database system’s access control. It can be done using roles, grants and row-level security policies on transactions. You will notice that most databases have some type of access control. To control transactions, this can be further enhanced.

“Replicated systems can have varying levels of replication. The majority of blockchain systems are fully replicated. This means that each unit/data is available on all nodes/entities. Each node has a complete copy of the underlying data. Traditional database systems use a lower degree of replication. Each unit of data can be stored in two or three independent copies (such a hot standby setup), or in one or more copies (such a Hadoop setup). These settings allow for replication from a safety or backup perspective (eliminating a single point of failure). It is more of a trust or tamperproof perspective in the blockchain environment. (How do you trust small entities that control the data?) The trust assumptions and the application may allow for precise control over the level of replication.

The trust model is a set of assumptions about the trustworthiness and reliability of all participants within the system. This is usually the case for the nodes that perform different duties within the system. These entities are usually separate in terms of control. The database system’s function is to allow consensus between multiple databases nodes about shared data/resources. The ordering service component, e.g. ordering node 116 within the system, can help decentralize trust. It can also be configured to work with varying trust models. A single ordering node is the best and most efficient option if participants are able to trust each other for whatever reason. Another example is that the nodes might trust one another to not commit malicious acts, but still want some crash-resistant ordering. Another example is that nodes might not trust one another and an alternative ordering service could be used. If the trust model is such as some nodes are more trusted than others, the relevant ordering service component can be used to meet the system’s needs.

“FIG. 2. illustrates a communication sequence 200 among devices in a decentralized data base system, in accordance to an example embodiment. Referring to FIG. 2 shows a decentralized database that includes multiple database nodes 221-223 as well as an ordering system 230. A database query may be received from any one of the database nodes, e.g. database node 221. This query may be issued by a program or similar software that is part of the client system. Step 241: The client system 210 invokes the database command/function at the 221. The database node 221, in response, may execute the function (e.g. using serializable snap isolation), but not commit its results. The results can be stored in temporary storage, or other similar places. In 242, the database node 221, may acknowledge receipt. A database command can include one or several SQL commands, one, more DML commands, or similar. Database commands can be used to perform functions like reading, writing, editing, and so on. Parameters can be added to database commands to help identify the data to be processed. The client system issues transactions and provides snapshot ids (refers to a data snapshot). This allows for the same output on all nodes. Before issuing the transaction, the client system retrieves the most recent snapshot id from any of the nodes so it can add that snapshot id to the transaction message.

“Next, the database command can be forwarded to other database nodes within the decentralized database (i.e. database nodes 223, 223) in steps 234 and 244. Each database node may execute the database command on the database data under snapshot isolation (e.g. using the snapshot ID in the transaction message), but not yet commit results, just like the first database node 221. The 245 database node may transmit the command to an ordering service (e.g., ordering node 231) which could be part of one of the databases nodes or a separate node/service. FIG. 2 shows the ordering node as a separate node. 2.”

The ordering node 230 will decide whether or not to commit a transaction based on whether the distributed database implements either a trusted network, or an untrusted one. The ordering node 230 in an untrusted network may receive all transactions and verify the signatures of client systems that submitted them. It can also create a block for storage by using a trusted service. To improve system efficiency, the ordering node may process database commands in batches. The block that is created can contain multiple transactions and the data/information for each transaction.

“In an untrusted environment, ordering node 230 can add signatures to the block, and broadcast it to all database nodes in distributed database system in 246. Each of the 221-223 database nodes may verify the signature upon receiving the block and perform a serializability test to determine whether or not to commit/abort a transaction. The node executes the transaction if the transaction has not been received from client or other nodes. Each database node commits the transaction in its own order, but not necessarily at the same time. Regardless of whether the transaction has been committed or aborted, each database node records the block received from its ordering node in the immutable transaction log. This is an append only record of transactions within the distributed databases system. This block contains details about each transaction that was processed in this batch. The append-only log may contain information about the node that created the block and the client/signature who provided the initial database command. Each block can have a sequentially increasing block number. The snapshot id that is issued by the client system denotes a block num. A snapshot ID of 10 is a data snapshot, which is a collection of tables and rows that includes all the rows created by or modified in all transactions from blocks 1-10. A transaction in block 10 can delete a row that was created in transaction in block 5. This row is not visible in snapshot ID 10. A serializability check can also be done before committing. This will identify any new block that is greater than transaction?s snapshot id. The transaction will be aborted if the serializability test fails.

“Another example is that the ordering node (230) may work in a trusted environment. The signature doesn’t need to be verified or added in this case. Instead, ordering node 230 could receive the command in 245, build the block, then broadcast it to all other database nodes in 246. Each database node can perform a serializability test to determine whether the transaction should be committed or aborted after receiving the block. The block may also be stored by the database nodes along with additional information about each ordering node and client who issued the database command.

“FIG. 3A shows a process 300 that a database computing node 322 processes a command. FIG. 3B shows the contents of data block 328, which is stored in an immutable database log. This is in accordance to example embodiments. Referring to FIG. FIG. 3A shows that the database computing node 322 includes a processor 322, and a temporary memory space 324 (e.g. private workspace, cache RAM, RAM, etc.). A data store 326 and an append only database log 328 are also included in this node. The processor 322 receives a command from a client or another database node and executes it. However, the results of the execution of the database command may not be saved to the data store 326. They may instead be saved in temporary memory 324.

“In 312, the database 320 may forward the command to another database node, or an ordering node, that is also part of the decentralized system. The database node 320 can also receive a commit request that includes a block transactional data from an ordering node. The processor 322 can execute a read set version check on each transaction executed by creating a dependency graph to determine whether to commit/abort. The processor 322 can commit the transaction to the 326 data store if the transaction has not been received from client or other nodes. The processor 322 can also store the block received by the ordering node in the immutable append only database transaction log 328. The block contains details about each transaction that was processed, which could be a batch. The processor 322 can also contain information about the ordering node that generated a block, the client/signature who provided the initial database command for the decentralized database and other similar information within the append only database log 328.

FIG. 3B shows the contents of block information that could be stored in the append only database log 328. 3B. Referring to FIG. FIG. 3B shows that, as an example, the block in the append only database log 328 could contain one or more transactions, 340, which will be committed/processed at the database node. The block can store a database command 341 for each transaction 340 (e.g. SQL command, function etc.). Arguments passed to the command 342 (e.g. variable, database location etc. ), the transaction status (e.g. commit/abort 343), an identification of the ordering node 345 and 346, as well as the identity of the client who issued the initial database command.

“FIG. “FIG. The computing system that is used to perform the method 400, such as a decentralized database computing system, may be used. The computing system could include a server or cloud platform, a workstation, a user device, or a combination thereof. The method of 410 includes receiving a database command from the client system by a processing device. The database command may include a function and parameters that will be used by the database function. The database command could include an SQL command or DML command. SQL commands can include functions such as select, read and update. They also may include custom-designed functions. Parameters can include data that is sent to or processed by the database command. Locations in the database are examples of parameters (e.g. start location, end location and columns, rows, tables etc. Data values, table names, etc. You should know that the database computing system can be either a relational or non-relational system.

“In 420 the method involves executing the database command on the database data by the processing device. The database computing system might execute the command by using serializable snap isolation with a client-supplied snapshot ID within the database. This will allow for a consistent view of all aspects of the database. The method described in 430 also includes the transmission of the received database command via an interface to one or more databases that are part of a decentralized system. The database command can be forwarded to, for example, one or more database computing systems (i.e. nodes) within the distributed database system, an ordering Node (which could be included in a data base computing system or another entity), or the like.

“In response to an order from an ordering node within the decentralized database systems, the method in 440 includes committing the results of execution of the database command to a particular data store of that database system and storing information regarding the database command in an append only immutable log. In response to receiving a broadcast message from an ordering node, the process of committing executed results can be completed. This signal is sent to all decentralized database computing systems’ database nodes. The broadcast signal is transmitted to all database nodes and can be used to update their data stores with the latest transaction. The method may also include the determination to store information about the database command in an immutable transaction log. This is based on a setting made in a configuration file for the database computing system.

“In some instances, the storage of information about the command to a database in an append only immutable database log could also include the storage of information about the command to a database in an appendonly immutable table. Some embodiments may also include the storage of the information about the command in the append only immutable log. This could include the received block that contains the command and arguments, as well as the identity of the ordering service that created it, or the identity of the client that issued the command. Some embodiments of the information about a database command can also include the storage of a hash from a previous entry in the append-only, immutable log along with information about the database commands to create a chained ordered immutable log. Some embodiments allow the client to verify that the initial submission of the database command was signed with a valid certificate before committing the results or storing information about it.

The example embodiments can be implemented in hardware, in computer programs executed by a processor or in firmware, or any combination thereof. A computer program can be embedded on a computer-readable medium such as a storage media. A computer program could, for example, reside in random access memory. ), flash memory or read-only memory (??ROM?). ), erasable, programmable read only memory (?EPROM) ), Electrically erasable, programmable read only memory (?EEPROM) Registers, registers, hard drive, a removable disc, a compact disk read only memory (?CDROM?),?EEPROM? ), or any other storage medium that is known to the art.

“An example storage medium could be connected to the processor so that the processor can read and write to the storage medium. Alternativly, the storage medium could be integrated with the processor. The application-specific integrated circuit (?ASIC?) may house the processor and storage medium. Alternativly, the storage medium and processor may be located as separate components. FIG. FIG. 5 shows an example of a computer system architecture 500. It could be used to represent any of the components mentioned above, or it may be integrated into them all. A computer system 500 could be one device or multiple devices. The computer system 500 could be, for example, a database computing system or a server.

“FIG. “FIG. The computing system 500 (or node 505) is capable of performing any of these functions.

“In computing node 500 is a computer server/system 502, which can be used with many other general-purpose or special-purpose computing system environments. Computer system/server 502 may be used with the following computing systems and environments: personal computers, server computer systems and thin clients. Thin clients and thick clients can also be used. Multiprocessor systems, microprocessor-based system, set top boxes, multiprocessor-based systems, multiprocessor-based system, multiprocessor-based system, set top boxes, programmable consumer electronics. Network PCs, minicomputer system, mainframe computer system, distributed database computing system and distributed cloud computing environments which include any of these systems and devices.

“Computer server/server 502” may be described as a generalization of computer-executable instructions (such as program modules) that are executed by a computer. Program modules can include routines, programs and objects as well as components, logic, logic, data structures and data structures that execute specific tasks or implement abstract data types. In distributed cloud computing environments, computer system/server 502 can be used to perform tasks that are carried out by remote processing devices linked via a communications network. Program modules can be stored in remote and local computer system storage media, including memory storage devices, in a distributed cloud computing environment.

“As shown at FIG. “As shown in FIG. 5, computer system/server 500 in computing node 500 is shown as a general-purpose computing unit. Computer system/server 502 components may include one or more processors/processing units 504 (i.e. processors), system memory 506, and bus that links various components, including processor 506 to processor 504. A database computing system 112 may be the computing node 500. 1 or more computing systems, devices, etc. Or a combination of devices, such as a server, cloud platform or database. The computing node 500 can also perform the 400-step method as shown in FIG. 4.”

The bus can be one or more of the following types of bus structures: a memory bus, microchannel architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA), local bus and a processor. These architectures include Industry Standard Architecture, Micro Channel Architecture, Enhanced ISA, EISA, Video Electronics Standards Association, local bus, Video Component Interconnects, and Peripheral Communication Interconnects (PCI).

Computer system/server 502 usually includes a variety computer system readable media. These media can be any media that is available to computer system/server 502. It includes volatile and nonvolatile media, as well as removable and nonremovable media. In one embodiment, system memory 506 implements the flow charts of the other figures. System memory 506 may include computer-readable media, such as volatile memory and cache memory 512. Another example is the possibility of a data store containing database tables. It could be either a relational or non-relational format.

“Computer system/server 502 may further include other removable/non-removable, volatile/non-volatile computer system storage media. Storage system 514, which is not shown, can be used to read from or write to non-removable and non-volatile magnetic media. It is commonly called a ‘hard drive?. A magnetic disk drive that can read from and write to a non-volatile magnetic disc (e.g., a “floppy disk”) is possible, although it is not shown. An optical disk drive can be used to read from and write to removable optical media such as CD-ROMs, DVD-ROMs, or other optical media. Each can be connected to a bus via one or more data media interfaces. Memory 506 can include at most one program product, e.g. one, that is configured to perform the functions of different embodiments of an application.

Program/utility 516 may store a set of (at least one!) program modules 518 in memory 506 as an example. This includes operating systems, application programs, program modules, program data, and other programs. A networking environment may be implemented in each operating system, application program, or combination thereof. Program modules 518 typically perform the functions and/or methods of different embodiments of an application, as described herein.

Aspects of the present invention may also be included in a method, system, or product for computer programs, as will anyone skilled in the art. Aspects of the present invention may be implemented as a completely hardware embodiment or an entirely software embodiment (including micro-code, firmware, resident software, and so on). Or an embodiment that combines software and hardware aspects, which may be called a?circuit? ?module? ?module? Aspects of the present invention may also be embodied in a computer program product that is stored on one or more computer-readable mediums with computer-readable program code.

“Computer system/server 502. may also communicate with one, two, or more external devices 520, such as a keyboard, display 522, and pointing device. One or more devices that allow a user interact with computer system/server 502. Computer system/server 502 can communicate with other computing devices. This communication can be done via I/O interfaces 524. Computer system/server 502 still has the ability to communicate with other networks, such as a local network (LAN), general wide area network, and/or public network (e.g. the Internet), via network adapter 526 (also known as a network interface). Network adapter 526 is shown communicating with other components of computer server 502 via a bus. Other hardware and/or programs could be used with computer system/server 502 even though they are not shown. Examples include but aren’t limited to microcode, device driver, redundant processing units and external disk drive arrays. RAID systems, tape drives and data archival systems.

According to different embodiments, processor 504 can receive a command from a client. A database command can include parameters and a database function. SQL commands/functions include insert, delete, join, select, and join. There are many commands that can be executed on a database. The processor 504 can execute the database command on data stored in the database based on parameters. To maintain database contents, snapshot isolation may be used to execute the database command. The processor 504 might wait to commit the results of executing a database command.

“Furthermore the network interface 526 can be accessed via a network (or any other interface like USB, cable or etc. The database command may be transmitted via direct connection or similar to any other databases within the decentralized system. In response to an order from a ordering node in the decentralized database systems, processor 504 can transmit the results of the execution of the database command to a database store. It may also record/store information regarding the database command as well as the parameters in an append only immutable log. The append-only, immutable database log is an immutable ledger that records database commands. It can be maintained by all decentralized database nodes. The append-only immutable log can be included in the system table of a database computing system. Each database node may have its own append only database log.

“In some embodiments, the network Interface 526 may be able to receive a block containing an identification of the database commands and arguments, as well as the ordering node. The block can also include the identity of the ordering node that created it, or the identity of the client that issued the command. The append-only, immutable database log may contain the block. The processor 504 may, in some embodiments, store a hash from a previous append-only database log entry together with information about the database command (e.g. within the block). This is to create a chained ordered immutable log. The ordering node may receive the hash or the database computing systems may create it. The processor 504 might commit the execution results of a database command to the database log and store information about the database commands in the append?only database log. This is done in response to verifying that the client who submitted the initial database command signed it with a valid certificate. The processor 504 might also decide to store information about the database command within the append-only, immutable log. This is based on a setting made in a configuration file for the database computing system.

“An exemplary embodiment of at most one of a system or method and a non-transitory computer-readable medium has been shown in the accompanying drawings and described in detail in the foregoing description. However, it is clear that the application is not limited by the disclosed embodiments and is capable of many rearrangements, modifications and substitutions as defined in the claims. The various figures’ capabilities can be achieved by any combination of one or more modules or components, or in a decentralized architecture that may include a transmitter, receiver, or a pair of both. One or more modules may perform all or part the functionality of individual modules. The functionality described in this document can be performed at different times and with respect to different events, whether they are internal or external to the components or modules. Information can also be sent between modules using at least one of the following: the Internet, a voice network or an Internet Protocol network. A wireless device, wired device, and/or multiple protocols. The messages that are sent and received by any module may be sent directly or via one or more modules.

“A?system’ is something that anyone skilled in the art can appreciate. A?system’ could be described as a personal computer or server, a console or a console, a personal assistant (PDA), a mobile phone, tablet computing device, smartphone, or any combination thereof. The functions described above are referred to as being performed by a “system”. This is not meant to limit the scope or limitations of the present application. However, it is intended to illustrate one of many possible embodiments. Methods, systems, and apparatuses described herein can be implemented in both localized and decentralized ways compatible with computing technology.

“It is important to note that not all system features are described here in modules. This is in order to emphasize their independence in implementation. A module could be implemented in a hardware circuit that includes custom very large scale integration (VLSI), gate arrays, off the shelf semiconductors like logic chips, transistors, and other discrete components. You can also implement a module in programmable hardware devices like field programmable gate arrangements, programmable array logics, programmable logic units, and the like.

“A module can also be implemented in software to allow execution by different types of processors. A unit of executable code can, for example, contain one or more physical blocks or logical blocks that include computer instructions. These instructions may be organized in a number of ways, such as object, procedure, function. The executables of an identified unit of executable code do not have to be physically located together. They may contain different instructions that are stored in different locations and, when combined logically, form the module. Modules can also be stored on computer-readable media, such as a hard drive, flash device or random access memory (RAM), tape or any other medium that stores data.

A module of executable software could contain one or more instructions and can be distributed across multiple code segments, between different programs, or across multiple memory devices. Similar to operational data, it can be identified and illustrated in modules. It may also be organized into any type of data structure and in any form. Operational data can be collected in one data set or distributed across multiple locations, including different storage devices. They may also exist at least partially as electronic signals within a system or network.

It will be clear that components of the invention, as shown in the figures, can be placed and designed in many different ways. The detailed descriptions of the embodiments are not meant to limit the scope or claim of the application. They only represent a few embodiments of that application.

“One with ordinary skill in art will quickly understand that the steps described above can be performed in a different order and/or with hardware elements that are not disclosed. Although the preferred embodiments have been described, it is obvious to those skilled in the art that there are many modifications, variations and other constructions.

Summary for “Distributed blockchain database with blockchain attributes”

A blockchain can be used to store transactional data regarding the exchange or goods of assets (e.g. monetary, goods, etc.). When certain conditions are met, asset-based exchanges can be executed within a blockchain. The transaction results are stored in a Blockchain ledger that is replicated across multiple blockchain nodes. This information can be provided by any entity or individual to a public blockchain. It should be checked and verified. This is called consensus. A blockchain system relies on a consensus, which transfers authority and trust to a network. It allows its peers (i.e., Blockchain peers) to record transactions in a public “block” and create a unique ‘chain. A blockchain is also known as. A blockchain uses cryptography via hash codes to authenticate a transaction source. This eliminates the need for any central intermediary.

A distributed database system is one in which different storage devices are controlled by the same processor. The distributed database system could be located in different locations in the same physical area or spread over multiple computers. Distributed databases can store data on multiple computers. This allows transactions to be processed by many machines instead of just one. The distributed database uses duplication to ensure that all databases are up-to-date. The system first identifies a master database and then copies the contents to the slave databases. The process of duplication is usually completed within a specified time frame. This is done to ensure that all locations have the same data. Users can only modify the master database during the duplication process. This protects local data from being overwritten. The master database node in the above master-slave distributed data base architecture is trusted by all slaves as a single entity that owns/controls the system. In multi-master distributed databases architectures, all masters trust each other’s data as a single entity own/control the systems. In contrast, in our proposed decentralized system architecture for database systems, each database node is controlled/owned by a different entity. One entity can not trust another entity.

“In one embodiment, there is a computing device that includes one or several processors that can receive a database command form a client system. The database command may include a function and parameters that will be used by the function to execute the database commands on database data. An interface that transmits the database command to other databases within a decentralized system is also provided. The processor may also be configured to receive a request from an ordering point of the decentralized system to execute the database command and to store information about it in an appendable immutable log.

“Another example embodiment provides a method that includes one of two things: receiving, from a processing device a database commands from a client systems, the database commands comprising a function to be used by that function, executing that database command on the database data, transmitting, via an interface, the received command to one or several other databases that are part of a decentralized system of database systems, and, in response to receiving a request form an ordering node of that decentralized system, committing the results of the log.

“Another example embodiment provides a non-transitory computer-readable medium that contains program instructions. These instructions, when executed, cause a computer’s to receive a database command from client systems. The database command comprises a function and parameters that can be used by that function. It also transmits, via an interface, the database commands to other databases within a decentralized system. In response to an order from an ordering node, the processing device commits the results of execution to a data store. Information about the command is stored in an append-only database log.

“Other features or modifications may be apparent in the following description when taken together with the drawings, and the claims.”

It will be apparent that components of the present invention, as described and illustrated in the figure herein, can be arranged in many different ways. The following description of at least one embodiment of a method or apparatus, non-transitory computer-readable medium, and system as illustrated in the attached figures is not intended as limiting the scope of this application. It is only representative of some embodiments.

“The features, structure, and characteristics described in this specification can be combined in any way that is appropriate throughout the embodiments. The use of phrases like?example embodiments’,?some embodiments?”, or similar language throughout this specification indicates that a particular feature or structure described in connection to an embodiment could be included in at least one embodiment. It is not to be taken to mean that it is omitted from any other embodiments. The phrases “example embodiments”, “in some embodiments,” or “in other embodiments” or similar terms may refer to the same group. Furthermore, the features, structures, and characteristics described may be combined in any way in one or more embodiments.

“In addition, the term’message’ may be used in the description of embodiments. While the term?message? may be used to describe embodiments, the application can be applied to any type of network data such as packet, frame, or datagram. The term “message” is used here. The term?message? or?request’ can be used interchangeably. or?request? may contain packet, frame, datagram and any equivalents thereof. While certain types of signals and messages may be shown in certain embodiments, they are not limited by a particular type of message or signaling request. The application, however, is not restricted to a specific type of signaling.

“Instagram” refers to a distributed database system. In another embodiment, it refers to a distributed database computing system. It may contain blockchain attributes that increase the security and storage of the database, while still allowing the database to process rich transactional queries (e.g. SQL, DML and DDL). The blockchain system can be a complex architecture and consume excessive resources. A blockchain system can be too complex for some use cases. These examples show a decentralized database system which can incrementally implement the blockchain attributes. Each attribute can also be turned on/off in the system by changing a single setting. A user can set the number of supported blockchain attributes in the database.

There are many similarities between a database and a blockchain system. Smart contracts are similar to stored procedures in a database system. A blockchain system also permits access control that is based on roles, grants, and row-level security policies. There are important differences between a blockchain and a database. A blockchain system, for example, requires that developers create smart contracts in specific programming languages. An application, even if blockchain properties are available within a database can still be written in the same way as any other database. However, it may also have additional properties that are similar to a Blockchain system. A developer does not have to learn a new programming language. The database described in this article allows easy migration of existing applications, while leveraging blockchain capabilities and interfacing with similar systems within other organizations for business.

“Another difference with blockchain systems is that they do not support rich queries or complex joins of multiple pieces information. Blockchain properties can be supported within a database to allow rich query and transactional processing support (e.g. support for SQL queries and DML, DDL, and DML). These examples improve query and transaction performance by allowing everything to be handled in a single database. This is unlike a blockchain system that has many components built on top of the database (often duplicateing what is already being done within the database). Although relational and nonrelational databases can be used, certain elements like transactions and atomic operations may not exist in non-relational implementations. The database may perform the traditional functions, though in a modified way, such as inserting/updating/deleting elements, querying at various levels of complexity (using SQL in case of relational database), etc.”

“Another difference in distributed databases is that data replicas between the nodes of a database system, such as master-slave or multi-master database systems, may be trusted?. A distributed database node can send a message to another. The second node will trust the first node about the content and origin of the message. This assumption may be broken according to different embodiments. A notion of security amongst database replicas may then be implemented while taking advantage of existing replication capabilities within the data base. A trusted distributed database system that is owned by one entity can become a decentralized database system, where each databased node may be owned by another entity. The decentralized database system may include a notion of consensus and total order of transactions. This is to ensure that all databases nodes commit transactions in the exact same order, regardless of the order in which they are executed. A complete log of all transactions can also be maintained across all nodes. These concepts are not possible in a traditional distributed database.

Another aspect of the examples is that these properties can be implemented within a decentralized data base. The properties can also be configured incrementally using settings in a configuration file. If an application requires?immutability?, it can be set up to support that property without the need for multiple database nodes, complex cryptography, or even a total order among transactions. By popular definition, a blockchain system cannot exist without cryptographic security. The core property of decentralized trust is the cryptographic security.

“FIG. “FIG. Referring to FIG. Referring to FIG. One or more nodes may be included in the decentralized database 110. To ensure that transactions are ordered in a multi-node system, the decentralized database system 110 includes an ordering node (116). The database computing systems 112 can be connected directly to one another (e.g. via a USB interface). Or, they may be connected to each other via a network 112, such as via a USB interface. According to different embodiments, the decentralized system 110 can be used for execution and recording database queries. These database queries may be used in order to select, update, or interact with data stored within the data stores of decentralized system 110. For example, client systems 120 (e.g., computers, tablets, mobile devices, POS terminals, software applications, etc.) The client systems 120 may communicate with nodes 112 over a network like the Internet or a private network and send database commands to the database.

The ordering node 116 and the database node 112 may be databases servers that store and manage access to data. The individual nodes can be controlled by different controlling entities in this situation. All nodes 112 may have a complete replication of the database data. Each node 112 may have a copy of each database table, function, and so forth. However, this replication can be set up. After a protocol configuration in the system, nodes can interact with each other. The nodes 112 and 113 may communicate new transactions with one another, and each node can execute each transaction and receive the results. Other interactions can also be made between nodes, such as discovery and block transfer.

“Accordingly to different embodiments, the decentralized data base system 110 could implement multiple blockchain properties. The system 110 may include the following features:

These blockchain attributes can be enabled/disabled through a database configuration file, which is incorporated into the database computing system 112. The configuration file can add the following configurable Blockchain properties to the database. It can either be true/false, or it may take a name:

“IMMUTABLE=true/false”

“TAMPER_PROOF_ORDERER=true/false”

“TAMPER_PROOF_TOTALLY_ORDERED=true/false”

“ORDERING_TRUST_MODEL=Practical Byzantine Fault Tolerance (PBFT)”

“NON_REPUDIABILITY=true/false”

“Immutability and append-only transactions are database transactions that are added to and modified to existing data. Traditional database systems give more importance to data, while long-term only the actual data values are considered. Data is not appended to an immutable database. This ensures that the entire history and commands used to manipulate or access the data are preserved. Append-only transactions means that the transaction records are given to individual transactions. These transactions cannot be altered.

“To attain this blockchain attribute within database 110, a?ledger?” A?ledger, which is a table in the database system that can be used to store transaction logs for both committed and aborted transactions, may be implemented. A transaction log entry can be made during COMMIT/ABORT. The?ledger is not permitted to host database commands like insert, update, or delete. Administrators or users cannot execute database commands on the?ledger. You may instead be restricted to using the COMMIT/ABORT functions to enter transactions log entries. The above actions can be enabled by user/admin when they enable immutable Blockchain property. The database system will not create or manage a ‘ledger’ if it isn’t enabled. System table to keep immutable transaction logs.”

A hash-chained, totally ordered log of transactions is a method of protecting entries by hashing each entry. A classic log of transactions, such as A, B and C, is not tamperproof because later A could be replaced by D, or the order changed (such B, A, C). A hash-chained, totally ordered log looks more like this:

“Where each entry in the log contains a reference to the previous entry, and so forth. This database log can be maintained at multiple database nodes in a decentralized system. It provides an audit trail of transactions as each entry can be signed and timestamped. The transaction may be stored on?ledger instead of being just stored there. Instead of storing the transaction on?ledger, you can link them using hash chains. The transactions will then be stored onto?ledger. table in the order of the database node COMMIT/ABORT. This property indicates the order in which transactions are committed/aborted.

“There is also the option of ‘totally? An ordered log of transactions. When multiple database nodes participate in the decentralized system, the totally ordered blockchain property can be enabled. This blockchain property is important because transactions can be submitted to different databases nodes in different order. It ensures that all the database nodes are committing/aborting transactions in the same order. The?ledger? will have the same order of transactions. The?ledger? system table will contain the same ordered chain of transactions that are committed and aborted. The ordering service (e.g. ordering node 116) is capable of performing either trusted central ordering or trusted consensus based ordering to ensure that all nodes have the same order.

To control access to the database system, a membership service management system could be used. This module can authenticate and authorize all parties to interact with the system. This property can be described as non-repudiation. One party P cannot perform an action A, but later claim that they didn’t. Because the system can prove occurrence of all actions/interactions, then non-repudiation is guaranteed. Transactions signed may include transactions (the primary method of interfacing with the system). These transactions are cryptographically signed under the control of the membership service management software. Databases have traditionally provided roles and permissions that were associated with them. Non-repudiation can be achieved by using a membership management system embedded in the database. Signatures are used to control interaction. A query processor engine at the database node may include a cryptography module that verifies that the transaction has been signed by the correct entity. This is called non-repudiation. The transaction may be rejected by the database node. The?ledger table also contains the signature. The database node may also add the signature that was added to the transaction by the submitting entity.”

“Transactions, in this context, can be written as a stored procedure and are the only way to interact the system. Every transaction logic can be written in a stored procedure that is agreed upon by all parties to the blockchain network. Transactions can be used to create or update tables, modify rows, delete data, or query specific patterns. The system might restrict the access of different parties to certain resources/data. This feature is provided by the database system’s access control. It can be done using roles, grants and row-level security policies on transactions. You will notice that most databases have some type of access control. To control transactions, this can be further enhanced.

“Replicated systems can have varying levels of replication. The majority of blockchain systems are fully replicated. This means that each unit/data is available on all nodes/entities. Each node has a complete copy of the underlying data. Traditional database systems use a lower degree of replication. Each unit of data can be stored in two or three independent copies (such a hot standby setup), or in one or more copies (such a Hadoop setup). These settings allow for replication from a safety or backup perspective (eliminating a single point of failure). It is more of a trust or tamperproof perspective in the blockchain environment. (How do you trust small entities that control the data?) The trust assumptions and the application may allow for precise control over the level of replication.

The trust model is a set of assumptions about the trustworthiness and reliability of all participants within the system. This is usually the case for the nodes that perform different duties within the system. These entities are usually separate in terms of control. The database system’s function is to allow consensus between multiple databases nodes about shared data/resources. The ordering service component, e.g. ordering node 116 within the system, can help decentralize trust. It can also be configured to work with varying trust models. A single ordering node is the best and most efficient option if participants are able to trust each other for whatever reason. Another example is that the nodes might trust one another to not commit malicious acts, but still want some crash-resistant ordering. Another example is that nodes might not trust one another and an alternative ordering service could be used. If the trust model is such as some nodes are more trusted than others, the relevant ordering service component can be used to meet the system’s needs.

“FIG. 2. illustrates a communication sequence 200 among devices in a decentralized data base system, in accordance to an example embodiment. Referring to FIG. 2 shows a decentralized database that includes multiple database nodes 221-223 as well as an ordering system 230. A database query may be received from any one of the database nodes, e.g. database node 221. This query may be issued by a program or similar software that is part of the client system. Step 241: The client system 210 invokes the database command/function at the 221. The database node 221, in response, may execute the function (e.g. using serializable snap isolation), but not commit its results. The results can be stored in temporary storage, or other similar places. In 242, the database node 221, may acknowledge receipt. A database command can include one or several SQL commands, one, more DML commands, or similar. Database commands can be used to perform functions like reading, writing, editing, and so on. Parameters can be added to database commands to help identify the data to be processed. The client system issues transactions and provides snapshot ids (refers to a data snapshot). This allows for the same output on all nodes. Before issuing the transaction, the client system retrieves the most recent snapshot id from any of the nodes so it can add that snapshot id to the transaction message.

“Next, the database command can be forwarded to other database nodes within the decentralized database (i.e. database nodes 223, 223) in steps 234 and 244. Each database node may execute the database command on the database data under snapshot isolation (e.g. using the snapshot ID in the transaction message), but not yet commit results, just like the first database node 221. The 245 database node may transmit the command to an ordering service (e.g., ordering node 231) which could be part of one of the databases nodes or a separate node/service. FIG. 2 shows the ordering node as a separate node. 2.”

The ordering node 230 will decide whether or not to commit a transaction based on whether the distributed database implements either a trusted network, or an untrusted one. The ordering node 230 in an untrusted network may receive all transactions and verify the signatures of client systems that submitted them. It can also create a block for storage by using a trusted service. To improve system efficiency, the ordering node may process database commands in batches. The block that is created can contain multiple transactions and the data/information for each transaction.

“In an untrusted environment, ordering node 230 can add signatures to the block, and broadcast it to all database nodes in distributed database system in 246. Each of the 221-223 database nodes may verify the signature upon receiving the block and perform a serializability test to determine whether or not to commit/abort a transaction. The node executes the transaction if the transaction has not been received from client or other nodes. Each database node commits the transaction in its own order, but not necessarily at the same time. Regardless of whether the transaction has been committed or aborted, each database node records the block received from its ordering node in the immutable transaction log. This is an append only record of transactions within the distributed databases system. This block contains details about each transaction that was processed in this batch. The append-only log may contain information about the node that created the block and the client/signature who provided the initial database command. Each block can have a sequentially increasing block number. The snapshot id that is issued by the client system denotes a block num. A snapshot ID of 10 is a data snapshot, which is a collection of tables and rows that includes all the rows created by or modified in all transactions from blocks 1-10. A transaction in block 10 can delete a row that was created in transaction in block 5. This row is not visible in snapshot ID 10. A serializability check can also be done before committing. This will identify any new block that is greater than transaction?s snapshot id. The transaction will be aborted if the serializability test fails.

“Another example is that the ordering node (230) may work in a trusted environment. The signature doesn’t need to be verified or added in this case. Instead, ordering node 230 could receive the command in 245, build the block, then broadcast it to all other database nodes in 246. Each database node can perform a serializability test to determine whether the transaction should be committed or aborted after receiving the block. The block may also be stored by the database nodes along with additional information about each ordering node and client who issued the database command.

“FIG. 3A shows a process 300 that a database computing node 322 processes a command. FIG. 3B shows the contents of data block 328, which is stored in an immutable database log. This is in accordance to example embodiments. Referring to FIG. FIG. 3A shows that the database computing node 322 includes a processor 322, and a temporary memory space 324 (e.g. private workspace, cache RAM, RAM, etc.). A data store 326 and an append only database log 328 are also included in this node. The processor 322 receives a command from a client or another database node and executes it. However, the results of the execution of the database command may not be saved to the data store 326. They may instead be saved in temporary memory 324.

“In 312, the database 320 may forward the command to another database node, or an ordering node, that is also part of the decentralized system. The database node 320 can also receive a commit request that includes a block transactional data from an ordering node. The processor 322 can execute a read set version check on each transaction executed by creating a dependency graph to determine whether to commit/abort. The processor 322 can commit the transaction to the 326 data store if the transaction has not been received from client or other nodes. The processor 322 can also store the block received by the ordering node in the immutable append only database transaction log 328. The block contains details about each transaction that was processed, which could be a batch. The processor 322 can also contain information about the ordering node that generated a block, the client/signature who provided the initial database command for the decentralized database and other similar information within the append only database log 328.

FIG. 3B shows the contents of block information that could be stored in the append only database log 328. 3B. Referring to FIG. FIG. 3B shows that, as an example, the block in the append only database log 328 could contain one or more transactions, 340, which will be committed/processed at the database node. The block can store a database command 341 for each transaction 340 (e.g. SQL command, function etc.). Arguments passed to the command 342 (e.g. variable, database location etc. ), the transaction status (e.g. commit/abort 343), an identification of the ordering node 345 and 346, as well as the identity of the client who issued the initial database command.

“FIG. “FIG. The computing system that is used to perform the method 400, such as a decentralized database computing system, may be used. The computing system could include a server or cloud platform, a workstation, a user device, or a combination thereof. The method of 410 includes receiving a database command from the client system by a processing device. The database command may include a function and parameters that will be used by the database function. The database command could include an SQL command or DML command. SQL commands can include functions such as select, read and update. They also may include custom-designed functions. Parameters can include data that is sent to or processed by the database command. Locations in the database are examples of parameters (e.g. start location, end location and columns, rows, tables etc. Data values, table names, etc. You should know that the database computing system can be either a relational or non-relational system.

“In 420 the method involves executing the database command on the database data by the processing device. The database computing system might execute the command by using serializable snap isolation with a client-supplied snapshot ID within the database. This will allow for a consistent view of all aspects of the database. The method described in 430 also includes the transmission of the received database command via an interface to one or more databases that are part of a decentralized system. The database command can be forwarded to, for example, one or more database computing systems (i.e. nodes) within the distributed database system, an ordering Node (which could be included in a data base computing system or another entity), or the like.

“In response to an order from an ordering node within the decentralized database systems, the method in 440 includes committing the results of execution of the database command to a particular data store of that database system and storing information regarding the database command in an append only immutable log. In response to receiving a broadcast message from an ordering node, the process of committing executed results can be completed. This signal is sent to all decentralized database computing systems’ database nodes. The broadcast signal is transmitted to all database nodes and can be used to update their data stores with the latest transaction. The method may also include the determination to store information about the database command in an immutable transaction log. This is based on a setting made in a configuration file for the database computing system.

“In some instances, the storage of information about the command to a database in an append only immutable database log could also include the storage of information about the command to a database in an appendonly immutable table. Some embodiments may also include the storage of the information about the command in the append only immutable log. This could include the received block that contains the command and arguments, as well as the identity of the ordering service that created it, or the identity of the client that issued the command. Some embodiments of the information about a database command can also include the storage of a hash from a previous entry in the append-only, immutable log along with information about the database commands to create a chained ordered immutable log. Some embodiments allow the client to verify that the initial submission of the database command was signed with a valid certificate before committing the results or storing information about it.

The example embodiments can be implemented in hardware, in computer programs executed by a processor or in firmware, or any combination thereof. A computer program can be embedded on a computer-readable medium such as a storage media. A computer program could, for example, reside in random access memory. ), flash memory or read-only memory (??ROM?). ), erasable, programmable read only memory (?EPROM) ), Electrically erasable, programmable read only memory (?EEPROM) Registers, registers, hard drive, a removable disc, a compact disk read only memory (?CDROM?),?EEPROM? ), or any other storage medium that is known to the art.

“An example storage medium could be connected to the processor so that the processor can read and write to the storage medium. Alternativly, the storage medium could be integrated with the processor. The application-specific integrated circuit (?ASIC?) may house the processor and storage medium. Alternativly, the storage medium and processor may be located as separate components. FIG. FIG. 5 shows an example of a computer system architecture 500. It could be used to represent any of the components mentioned above, or it may be integrated into them all. A computer system 500 could be one device or multiple devices. The computer system 500 could be, for example, a database computing system or a server.

“FIG. “FIG. The computing system 500 (or node 505) is capable of performing any of these functions.

“In computing node 500 is a computer server/system 502, which can be used with many other general-purpose or special-purpose computing system environments. Computer system/server 502 may be used with the following computing systems and environments: personal computers, server computer systems and thin clients. Thin clients and thick clients can also be used. Multiprocessor systems, microprocessor-based system, set top boxes, multiprocessor-based systems, multiprocessor-based system, multiprocessor-based system, set top boxes, programmable consumer electronics. Network PCs, minicomputer system, mainframe computer system, distributed database computing system and distributed cloud computing environments which include any of these systems and devices.

“Computer server/server 502” may be described as a generalization of computer-executable instructions (such as program modules) that are executed by a computer. Program modules can include routines, programs and objects as well as components, logic, logic, data structures and data structures that execute specific tasks or implement abstract data types. In distributed cloud computing environments, computer system/server 502 can be used to perform tasks that are carried out by remote processing devices linked via a communications network. Program modules can be stored in remote and local computer system storage media, including memory storage devices, in a distributed cloud computing environment.

“As shown at FIG. “As shown in FIG. 5, computer system/server 500 in computing node 500 is shown as a general-purpose computing unit. Computer system/server 502 components may include one or more processors/processing units 504 (i.e. processors), system memory 506, and bus that links various components, including processor 506 to processor 504. A database computing system 112 may be the computing node 500. 1 or more computing systems, devices, etc. Or a combination of devices, such as a server, cloud platform or database. The computing node 500 can also perform the 400-step method as shown in FIG. 4.”

The bus can be one or more of the following types of bus structures: a memory bus, microchannel architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA), local bus and a processor. These architectures include Industry Standard Architecture, Micro Channel Architecture, Enhanced ISA, EISA, Video Electronics Standards Association, local bus, Video Component Interconnects, and Peripheral Communication Interconnects (PCI).

Computer system/server 502 usually includes a variety computer system readable media. These media can be any media that is available to computer system/server 502. It includes volatile and nonvolatile media, as well as removable and nonremovable media. In one embodiment, system memory 506 implements the flow charts of the other figures. System memory 506 may include computer-readable media, such as volatile memory and cache memory 512. Another example is the possibility of a data store containing database tables. It could be either a relational or non-relational format.

“Computer system/server 502 may further include other removable/non-removable, volatile/non-volatile computer system storage media. Storage system 514, which is not shown, can be used to read from or write to non-removable and non-volatile magnetic media. It is commonly called a ‘hard drive?. A magnetic disk drive that can read from and write to a non-volatile magnetic disc (e.g., a “floppy disk”) is possible, although it is not shown. An optical disk drive can be used to read from and write to removable optical media such as CD-ROMs, DVD-ROMs, or other optical media. Each can be connected to a bus via one or more data media interfaces. Memory 506 can include at most one program product, e.g. one, that is configured to perform the functions of different embodiments of an application.

Program/utility 516 may store a set of (at least one!) program modules 518 in memory 506 as an example. This includes operating systems, application programs, program modules, program data, and other programs. A networking environment may be implemented in each operating system, application program, or combination thereof. Program modules 518 typically perform the functions and/or methods of different embodiments of an application, as described herein.

Aspects of the present invention may also be included in a method, system, or product for computer programs, as will anyone skilled in the art. Aspects of the present invention may be implemented as a completely hardware embodiment or an entirely software embodiment (including micro-code, firmware, resident software, and so on). Or an embodiment that combines software and hardware aspects, which may be called a?circuit? ?module? ?module? Aspects of the present invention may also be embodied in a computer program product that is stored on one or more computer-readable mediums with computer-readable program code.

“Computer system/server 502. may also communicate with one, two, or more external devices 520, such as a keyboard, display 522, and pointing device. One or more devices that allow a user interact with computer system/server 502. Computer system/server 502 can communicate with other computing devices. This communication can be done via I/O interfaces 524. Computer system/server 502 still has the ability to communicate with other networks, such as a local network (LAN), general wide area network, and/or public network (e.g. the Internet), via network adapter 526 (also known as a network interface). Network adapter 526 is shown communicating with other components of computer server 502 via a bus. Other hardware and/or programs could be used with computer system/server 502 even though they are not shown. Examples include but aren’t limited to microcode, device driver, redundant processing units and external disk drive arrays. RAID systems, tape drives and data archival systems.

According to different embodiments, processor 504 can receive a command from a client. A database command can include parameters and a database function. SQL commands/functions include insert, delete, join, select, and join. There are many commands that can be executed on a database. The processor 504 can execute the database command on data stored in the database based on parameters. To maintain database contents, snapshot isolation may be used to execute the database command. The processor 504 might wait to commit the results of executing a database command.

“Furthermore the network interface 526 can be accessed via a network (or any other interface like USB, cable or etc. The database command may be transmitted via direct connection or similar to any other databases within the decentralized system. In response to an order from a ordering node in the decentralized database systems, processor 504 can transmit the results of the execution of the database command to a database store. It may also record/store information regarding the database command as well as the parameters in an append only immutable log. The append-only, immutable database log is an immutable ledger that records database commands. It can be maintained by all decentralized database nodes. The append-only immutable log can be included in the system table of a database computing system. Each database node may have its own append only database log.

“In some embodiments, the network Interface 526 may be able to receive a block containing an identification of the database commands and arguments, as well as the ordering node. The block can also include the identity of the ordering node that created it, or the identity of the client that issued the command. The append-only, immutable database log may contain the block. The processor 504 may, in some embodiments, store a hash from a previous append-only database log entry together with information about the database command (e.g. within the block). This is to create a chained ordered immutable log. The ordering node may receive the hash or the database computing systems may create it. The processor 504 might commit the execution results of a database command to the database log and store information about the database commands in the append?only database log. This is done in response to verifying that the client who submitted the initial database command signed it with a valid certificate. The processor 504 might also decide to store information about the database command within the append-only, immutable log. This is based on a setting made in a configuration file for the database computing system.

“An exemplary embodiment of at most one of a system or method and a non-transitory computer-readable medium has been shown in the accompanying drawings and described in detail in the foregoing description. However, it is clear that the application is not limited by the disclosed embodiments and is capable of many rearrangements, modifications and substitutions as defined in the claims. The various figures’ capabilities can be achieved by any combination of one or more modules or components, or in a decentralized architecture that may include a transmitter, receiver, or a pair of both. One or more modules may perform all or part the functionality of individual modules. The functionality described in this document can be performed at different times and with respect to different events, whether they are internal or external to the components or modules. Information can also be sent between modules using at least one of the following: the Internet, a voice network or an Internet Protocol network. A wireless device, wired device, and/or multiple protocols. The messages that are sent and received by any module may be sent directly or via one or more modules.

“A?system’ is something that anyone skilled in the art can appreciate. A?system’ could be described as a personal computer or server, a console or a console, a personal assistant (PDA), a mobile phone, tablet computing device, smartphone, or any combination thereof. The functions described above are referred to as being performed by a “system”. This is not meant to limit the scope or limitations of the present application. However, it is intended to illustrate one of many possible embodiments. Methods, systems, and apparatuses described herein can be implemented in both localized and decentralized ways compatible with computing technology.

“It is important to note that not all system features are described here in modules. This is in order to emphasize their independence in implementation. A module could be implemented in a hardware circuit that includes custom very large scale integration (VLSI), gate arrays, off the shelf semiconductors like logic chips, transistors, and other discrete components. You can also implement a module in programmable hardware devices like field programmable gate arrangements, programmable array logics, programmable logic units, and the like.

“A module can also be implemented in software to allow execution by different types of processors. A unit of executable code can, for example, contain one or more physical blocks or logical blocks that include computer instructions. These instructions may be organized in a number of ways, such as object, procedure, function. The executables of an identified unit of executable code do not have to be physically located together. They may contain different instructions that are stored in different locations and, when combined logically, form the module. Modules can also be stored on computer-readable media, such as a hard drive, flash device or random access memory (RAM), tape or any other medium that stores data.

A module of executable software could contain one or more instructions and can be distributed across multiple code segments, between different programs, or across multiple memory devices. Similar to operational data, it can be identified and illustrated in modules. It may also be organized into any type of data structure and in any form. Operational data can be collected in one data set or distributed across multiple locations, including different storage devices. They may also exist at least partially as electronic signals within a system or network.

It will be clear that components of the invention, as shown in the figures, can be placed and designed in many different ways. The detailed descriptions of the embodiments are not meant to limit the scope or claim of the application. They only represent a few embodiments of that application.

“One with ordinary skill in art will quickly understand that the steps described above can be performed in a different order and/or with hardware elements that are not disclosed. Although the preferred embodiments have been described, it is obvious to those skilled in the art that there are many modifications, variations and other constructions.

Click here to view the patent on Google Patents.

How to Search for Patents

A patent search is the first step to getting your patent. You can do a google patent search or do a USPTO search. Patent-pending is the term for the product that has been covered by the patent application. You can search the public pair to find the patent application. After the patent office approves your application, you will be able to do a patent number look to locate the patent issued. Your product is now patentable. You can also use the USPTO search engine. See below for details. You can get help from a patent lawyer. Patents in the United States are granted by the US trademark and patent office or the United States Patent and Trademark office. This office also reviews trademark applications.

Are you interested in similar patents? These are the steps to follow:

1. Brainstorm terms to describe your invention, based on its purpose, composition, or use.

Write down a brief, but precise description of the invention. Don’t use generic terms such as “device”, “process,” or “system”. Consider synonyms for the terms you chose initially. Next, take note of important technical terms as well as keywords.

Use the questions below to help you identify keywords or concepts.

  • What is the purpose of the invention Is it a utilitarian device or an ornamental design?
  • Is invention a way to create something or perform a function? Is it a product?
  • What is the composition and function of the invention? What is the physical composition of the invention?
  • What’s the purpose of the invention
  • What are the technical terms and keywords used to describe an invention’s nature? A technical dictionary can help you locate the right terms.

2. These terms will allow you to search for relevant Cooperative Patent Classifications at Classification Search Tool. If you are unable to find the right classification for your invention, scan through the classification’s class Schemas (class schedules) and try again. If you don’t get any results from the Classification Text Search, you might consider substituting your words to describe your invention with synonyms.

3. Check the CPC Classification Definition for confirmation of the CPC classification you found. If the selected classification title has a blue box with a “D” at its left, the hyperlink will take you to a CPC classification description. CPC classification definitions will help you determine the applicable classification’s scope so that you can choose the most relevant. These definitions may also include search tips or other suggestions that could be helpful for further research.

4. The Patents Full-Text Database and the Image Database allow you to retrieve patent documents that include the CPC classification. By focusing on the abstracts and representative drawings, you can narrow down your search for the most relevant patent publications.

5. This selection of patent publications is the best to look at for any similarities to your invention. Pay attention to the claims and specification. Refer to the applicant and patent examiner for additional patents.

6. You can retrieve published patent applications that match the CPC classification you chose in Step 3. You can also use the same search strategy that you used in Step 4 to narrow your search results to only the most relevant patent applications by reviewing the abstracts and representative drawings for each page. Next, examine all published patent applications carefully, paying special attention to the claims, and other drawings.

7. You can search for additional US patent publications by keyword searching in AppFT or PatFT databases, as well as classification searching of patents not from the United States per below. Also, you can use web search engines to search non-patent literature disclosures about inventions. Here are some examples:

  • Add keywords to your search. Keyword searches may turn up documents that are not well-categorized or have missed classifications during Step 2. For example, US patent examiners often supplement their classification searches with keyword searches. Think about the use of technical engineering terminology rather than everyday words.
  • Search for foreign patents using the CPC classification. Then, re-run the search using international patent office search engines such as Espacenet, the European Patent Office’s worldwide patent publication database of over 130 million patent publications. Other national databases include:
  • Search non-patent literature. Inventions can be made public in many non-patent publications. It is recommended that you search journals, books, websites, technical catalogs, conference proceedings, and other print and electronic publications.

To review your search, you can hire a registered patent attorney to assist. A preliminary search will help one better prepare to talk about their invention and other related inventions with a professional patent attorney. In addition, the attorney will not spend too much time or money on patenting basics.

Download patent guide file – Click here