Encrypted data entry blockchain data structure

Abstract

A method for securely storing and transferring data using a blockchain structure. The blockchain structure runs on a local node and communicates with an arbitrating server and cloud infrastructure over SSH. A local application coordinates the order of appended blocks, where each block is a flat file that represents the block order using a corresponding file name. Data entry and retrieval is performed when the plaintext data is only available in local memory, decrypted by an authorized client. Data is only written to disk in encrypted form.

Description

[0001] Cross-referencing related applications

[0002] This application claims priority to U.S. Provisional Patent Application No. 62 / 985,129, filed March 4, 2020, which is incorporated herein by reference in its entirety. Technical Field

[0003] This disclosure relates to determining the cryptographic data structures involved in storing data in a distributed network. Background Technology

[0004] Conventional databases have many vulnerabilities. For example, many databases suffer from security issues. Data is stored or transmitted in an unencrypted manner, making it a potential target for malicious actors. Every day, company databases are compromised and records are stolen. A second problem arises from corruption—the complete loss of database data due to external factors such as lightning strikes, power outages, human error, or unforeseen circumstances.

[0005] Blockchain data storage leverages the inherent immutability of known blockchain systems and the difficulty of modifying the overall data structure. Specifically, the stored data is associated with financial systems rather than actual data storage systems.

[0006] Known data encryption schemes often have inherent vulnerabilities that make them targets for attackers. Attached Figure Description

[0007] Figure 1 It is a block diagram containing various cryptographic addresses and entities within a data structure.

[0008] Figure 2 This is a diagram illustrating the relationship between the client front-end and accessibility to the blockchain.

[0009] Figure 3 This is a flowchart illustrating a method for attaching data to a blockchain.

[0010] Figure 4 This is a block diagram of an arbiter server in a peer-to-peer network.

[0011] Figure 5 This is a flowchart illustrating a method for retrieving legitimate data from a blockchain.

[0012] Figure 6 It is a screenshot of the data entry interface and the associated blockchain.

[0013] Figure 7 This is a screenshot of a blockchain viewer application drawn from the blockchain.

[0014] Figure 8This is a block diagram of an exemplary computing system. Detailed Implementation

[0015] A typical blockchain is a cryptographic data structure in which a distributed network facilitates an immutable ledger of data. Blockchain systems are typically associated with a group of users identified via cryptographic key pairs, which include a public key (identifying the user, acting as an address) and a private key (used to sign actions taken by the user, associated with the public key via a one-way function). New data is submitted to the network, and nodes within the network append that data to the end of the blockchain. Compared to traditional databases, blockchain systems offer several advantages. Specifically, because the structure only continues to grow, data is never lost. Because the network is distributed, synchronization between nodes means that a corrupted node can be repaired using data stored by its peers, thus preventing data loss due to corruption. Because the data is distributed and largely immutable, blockchains are also more difficult to attack than databases.

[0016] Fundamentally, a blockchain is a distributed linked list.

[0017] This paper describes a system where users of a given entity are every node on a distributed network. Each node does not need to be a complete node (e.g., storing the entire blockchain) to participate. When nodes log in after a period of inactivity, during synchronization, these nodes first retrieve the latest block in the chain and then work backwards from the genesis block. Data in the blocks is stored in small flat files containing the simplest expression of the information. The stored data is encrypted into ciphertext. Viewing the plaintext data is performed in memory to reduce the attack window for malicious users. For the purposes of this paper, "plaintext" is the complement of "ciphertext," referring to unencrypted or pre-encrypted data (in the case of multiple encryption cycles). Plaintext is one or more inputs to the function that generates the ciphertext.

[0018] Blockchain is immutable; that is, once appended, the data in a block is difficult (if not impossible) to change. However, data entry typically involves modification or editing of the data. When it is necessary to change the data in a given block, the system uses the block containing the relevant data as the genesis block to generate a new branch blockchain structure. As the data is edited, a new block is appended to the branch blockchain.

[0019] Figure 1The diagram illustrates the blockchain data structure for implementing branched blockchains. The main blockchain 20 begins with block 22 and includes blocks 24, 26, 28, and 28. The main blockchain 20 can be referred to as the first blockchain or the main blockchain. The number of blocks is for illustrative purposes only. In real-world use cases, the main blockchain 20 will comprise many, many blocks over time. Each block is a data store. That is, nodes submitting new data to the blockchain and thus submitting new blocks perform processing operations to ensure the new block is consistent with the previous or last block.

[0020] Blocks are not mined, but rather created each time a user transacts data. In one example, a user might save a two-page Word document, which becomes a block, and then a single-page document saved as another block. Blocks are created immediately and hashed like in a blockchain. This process is the same as creating data. For example, a user might open a blank Word document, type, and save it; that document then becomes a block.

[0021] Each block preferably contains some payload data, along with a block ID, last hash, new hash, user hash, time / date, and the username of the user who entered the data. The data is encrypted ciphertext when stored in blockchains 20 and 30. The block is additionally hashed using a corresponding key associated with the user who generated the block or the user who oversaw the block generation.

[0022] The payload or data can have any suitable size. A block can store a single bit or an entire document. Data scope includes fields on a form and / or the entire data form. In some embodiments, blocks in the chain are each file (e.g., a flat file) stored on disk. Embodiments of this system generate additional flat files for new blocks. The linked list aspect of the blockchain is supported by a file naming scheme, where filenames are dynamically created to include references to previous blocks. The block's payload or data is stored in a flat file.

[0023] Blockchain 20 is immutable. If a change is made on a node, forced synchronization will cause that node to be consistent with other nodes whose blocks remain unchanged. Data in the database is frequently changed for many legitimate reasons. In some embodiments, new data or edits to old data are appended to the top of blockchain 20 in future blocks 32. In some embodiments, legitimate data edits are appended to a branch blockchain 30 from a block containing the data to be edited. Branch blockchain 30 may be referred to as a second, third, or Nth blockchain, or a sub-chain. Branch blockchain 30 has a genesis block on the main blockchain 20. In some embodiments, when a given block on the main blockchain 20 is not the genesis block of branch blockchain 30, no edits to the relevant data are stored in the given block. The existence of a branch blockchain for that block indicates a modification to the data.

[0024] The third block 26 depicted in the diagram contains the data that the user wants to edit. The editing of this data is represented in Block 3-Start 34, rather than generating a new block on the main blockchain 20 in the future block 32 space. Block 3-Start 34 is the second block in branch blockchain 30, which uses the third block 26 of the main blockchain 20 as its new genesis block. As the data associated with the third block 26 is further edited, these edits result in a block being added to branch blockchain 30 in the future edit 36 ​​of the data in the third block.

[0025] When reading data associated with block 26, the system only needs to check the relevant branch blockchain 30 (if it exists), without needing to check the entire main blockchain 20 for any references to that data. The main blockchain 20 represents all data instances, while the branch blockchain 30 represents the change log and current state of a given data instance.

[0026] In some embodiments, the data in a block is encrypted. A key for decrypting the data in a given block is stored according to a user's node client replica. In these embodiments, not all instances of the node client can read / write all blocks. For example, in some embodiments, client A can read / write client A blocks, client B can read / write client B blocks, but client A cannot read / write client B blocks, and vice versa.

[0027] Figure 2This is a block diagram illustrating the relationship between the client front-end and accessibility to the blockchain. A given user operates a node of a data manipulation system 38. The data manipulation system 38 includes a user front-end UI 40 that references blockchains 20, 30 stored on disks, cloud servers, hard drives of blockchain network peer nodes, or other suitable storage media or locations. Data within blockchains 20, 30 is encrypted and decrypted in local system memory for use in the front-end UI 40. In this document, "memory" refers to random access memory ("RAM") or other volatile storage structures. Memory is distinguished from "disk" or "hard drive" storage, which refers to non-volatile storage.

[0028] The use of front-end UI 40 obscures the existence of blockchains 20 and 30, and users of front-end UI 40 may not be aware of their existence. Blockchains 20 and 30 are data structures that securely store user data. Blockchains 20 and 30 exist in the backend of data manipulation system 38, and users do not directly interact with them. Human users will not be able to decipher the block files because each block file contains encrypted and hashed data. Therefore, while front-end UI 40 is used to access decryptable data, malicious actors must have access to front-end UI 40 or local system storage.

[0029] The front-end UI 40 can be customized for the purposes of a given user or organization. Whatever data the user / organization needs, the front-end UI 40 will be built accordingly. When using the front-end UI 40, the user enters new data 42 via any domain or input interface presented in the front-end UI 40. While the entered new data 42 is still in local system memory, the data manipulation system 38 converts the data into a new block 46 on the blockchain 20. The new block 46 is appended to the end of the blockchain 20. The new data 42 is encrypted in memory in real time after being entered by the user. The encrypted data is then stored in the new block 46. In some embodiments, the block is written to the node, the server, and simultaneously sent to the cloud / backup drive. The blocks sent to the server and backup drive are accomplished using SSH transport that allows end-to-end encrypted tunneling.

[0030] When a user searches for previously entered data, the data manipulation system 38 triggers the process of retrieving data from blockchains 20 and 30. The data is decrypted and presented to the user on the front-end UI 40. Data is retrieved using the unencrypted user ID portion of each block. Based on the user ID, the system determines the block containing decryptable data. The data retrieval process is transparent to the user based on the operation of the front-end UI 40. The source of the data is not explicitly disclosed to the user. Data is retrieved from blockchains 20 and 30 and decrypted in storage. Once decrypted in storage, the plaintext data is presented to the user on the front-end UI 40.

[0031] In cases where a user modifies previously entered data, these changes (52) are made in memory, encrypted, and placed in a new block 46 or an edit block 54 on a branch blockchain 30 based on the implemented embodiment and / or the type of data being modified. In some embodiments without a branch blockchain 30, the edited data goes into a new block 46 and is appended to the main blockchain 20.

[0032] Data security is maintained by keeping unencrypted data off the hard drive. Compared to systems that transmit or store unencrypted data, attackers have a much narrower window to consume it.

[0033] Figure 3 This is a flowchart illustrating a method for attaching data to a blockchain. Users attach data to the blockchain via a front-end UI. Valid attachments can only be initiated by a logged-in user who has entered login credentials through the front-end UI. In some embodiments, a cryptographic key pair performs the ability to attach to the blockchain. Program code accessing the key pair in the front-end UI cannot be executed without being logged in. Therefore, in step 502, the system determines the current user's credentials. Credentials can be checked in various ways, including multi-factor authentication (MFA). A non-exhaustive list of factors may include locked geographic locations (e.g., the location of the device using the front-end UI), locked secondary devices, external time-to-live codes, biometric keys, and login credentials.

[0034] In step 504, the local node establishes a secure tunnel (e.g., SSH and / or SCP encrypted tunnel format) with the first server using login information. In some embodiments, the first server may be referred to as an arbitration server. The arbitration server is configured to coordinate block ordering when multiple nodes simultaneously attempt to attach to the blockchain. In step 506, the local node receives input data via a front-end UI and stores the data as variables in local system memory. The new data is displayed on the front-end UI by accessing the memory. The new data in plaintext is not stored on the local node's local disk drive. Whether the input data is attached to the main blockchain or a branch blockchain varies as the data retrieval process progresses (discussed in further detail below).

[0035] Based on the additional request from the local node, in step 508, the arbitration server generates a new block file or folder and synchronizes the file or folder name with the local node. The arbitration server maintains a linear ordering of blocks on the blockchain. When the arbitration server generates a new block file, it has already placed the local node's request at a given position on the blockchain. At this stage, the new block file or folder does not contain any payload data. In another embodiment, the local node first creates the new block file / folder and obtains a naming component from the arbitration server, which establishes a linked list referencing the last block. During the generation of new blocks, the last block may be changed based on blocks submitted by other nodes. The name of the new block is dynamically modified throughout the generation process to update the reference to the last block.

[0036] The process remains unchanged regardless of which part of the blockchain it is appended to. No matter where the new block goes, there is still a new block on some chain. The naming convention for new blocks indicates their order within the blockchain. Block names are dynamically generated to accommodate multiple nodes attempting to append data simultaneously. In some embodiments, the block file / folder naming convention includes appending "_x" to the end of the name, where x is the last block + ".bl" (e.g., a file type identifier). The file type identifier ".bl" is arbitrary and can use any file extension. The system is configured to identify specific file type identifiers based on system design. New blocks are named using the last block number.

[0037] In step 510, the local node synchronizes the last block with the arbitration server to ensure the node has the latest copy by comparing the latest hash. In step 512, identifying data is inserted into a file / folder for the new block. Identifying data includes: the hash of the last block inserted into the new block file, the logged-in user's user ID, the new block hash, and a timestamp / date stamp. Identifying data can be represented in the header section of the new block file or by using a delimiter. The synchronizer can reorder blocks if necessary (e.g., due to simultaneous commits) and ensure the integrity of the last hash. The filename is updated during the append process using a last block integer counter (in some embodiments, the update also includes the last hash). The file is also locked with permissions of 000 to ensure it cannot be modified by external sources. In some embodiments, the local node reorders blocks locally based on the timestamp of each received block.

[0038] In some embodiments, all parts of a block are encrypted within the block except for the ID, last block hash, and hash. In the new block system, log information is also included in the block itself. The block includes the ID (last block number (lastblock #)), the last hash of the previous block, the new hash, the time / date stamp, the login username that created the block, group affiliation, and all new data to be encrypted.

[0039] Synchronization is a background process initiated by a separate software tool (per node) and is automatic. No user input is required. When the computer restarts / turns on and runs silently in the background, synchronization loads at startup, synchronizing any missing or new blocks. Synchronization enables new blocks created during periods without internet access to be uploaded to servers or the cloud, making them available to other nodes. Renaming / reordering by block number in the filename, if necessary, is done automatically, and the blocks are organized by time / date stamp. If the timestamp is encrypted, the blocks are decrypted to evaluate the timestamp, then re-encrypted and renamed using the new block sort number.

[0040] In step 514, the local node encrypts the plaintext new data (in memory) and writes it into the ciphertext within the payload of the new block file / folder. Identification data, such as the last / new hash or user identifier, is not encrypted. In some embodiments, time / date is similarly not encrypted. In some embodiments, new data may be written to a local copy of the new block file / folder before encryption and vice versa. In this way, the plaintext of the new data does not exist outside the local system memory for longer than the time required to encrypt the plaintext.

[0041] Encryption is performed using a user-associated key. In some embodiments, the user-associated key is a private key or a user-associated cryptographic key pair. In some embodiments, the key used to encrypt new data is a separate unrelated key representing the permission level (e.g., a key shared by all users in a given user subclass). Depending on the permission level required to access the data, users at multiple levels in a user hierarchy may have multiple keys. Examples of suitable encryption methods include SHA3-512 bits and AES-128 or 256-bit level encryption. In some embodiments, the system uses a random strong password and a hardware key searched in a triple-nested array. In some embodiments, the same single key is used across all permission levels, and for a given user, the “key” refers to an association with a block number on which the system applies the single key to decrypt for that user. In those embodiments, the user’s key is a matter of protocol permissions, not a cryptographic relationship.

[0042] In step 516, the last block is resynchronized between the local node and the arbitration server to ensure the local node still has the latest version. In step 518, the new block is saved to the disk on the local node. In step 520, the local node uploads the saved new block to the arbitration server via a secure communication tunnel. Integrity is continuously checked to ensure the last block is indeed the last block (e.g., if the last block changes from 60 to 61 during saving, the node writes block 62, uploads it, and then uploads the new last block file numbered 62). The synchronizer exists to prevent simultaneous attempts to write two blocks with the same number.

[0043] In step 522, the new block is synchronized with other nodes and the second server. In some embodiments, the second server may be referred to as a cloud server. In step 524, a success or failure message is sent to the participating devices.

[0044] Blocks are transmitted to the server and cloud drive near real-time across all nodes, and reside on the server and backup drive. Nodes download the blocks back and then read the encrypted data into an array (in memory). The data is then decrypted within the array. The last block is appended twice—once before the block data is written (in step 512) and once after the block data is written (in step 516)—to ensure that a given block is indeed the last block. If the new last block is not yet on the server / backup drive, the arbitration server generates an error, and after a short wait, it tries again. The synchronizer ensures that there are no duplicate blocks, and if any two nodes happen to write the same block simultaneously (accurate to milliseconds), a reordering is performed—if so, a timestamp / datest is used to ensure order (again, accurate to milliseconds). The earliest time takes precedence.

[0045] Figure 4 This is a block diagram of the arbitration server 58 in the peer-to-peer network 56. The peer-to-peer network 56 includes multiple distributed nodes or peer nodes 60. Peer nodes 60 synchronize with copies of blockchain 20 stored on the arbitration server 58 and the cloud server 62. For local nodes operating on the peer-to-peer network 56, each peer node 60 does not necessarily have to store the full or latest version of blockchain 20.

[0046] While peer node 60 communicates with the network, synchronization of peer node 60 occurs at regular intervals; however, a given node 60 that has been offline for a period of time may not have the latest version of blockchain 20. In the event that a node rejoins the network after a period of inactivity, synchronization causes the node to receive all missing blocks. In some embodiments, peer nodes 60 communicate directly with each other and obtain updated synchronization data from each other while performing a periodic synchronization process on the blockchain data.

[0047] Synchronization is a simulation of the consensus process performed in traditional blockchains. Through synchronization, the immutability of blockchain 20 and 30 is imposed.

[0048] Figure 5 This is a flowchart illustrating the method for retrieving legitimate data from the blockchain. The user of the front-end UI is not explicitly aware of the blockchain's existence. Based on the front-end UI configuration, data requests from the blockchain can be made in various ways. However, ultimately, the front-end UI uses the search function. The search query used can be user-generated or generated based on the configuration and each given use case.

[0049] Similar to the attached data, users must log in to the front-end UI to retrieve the data in plaintext. Anyone with access to the blockchain can view the data, but it is stored in encrypted form and is incomprehensible to those who do not have (indirect) access through the front-end UI and the associated key. Therefore, in step 702, the local node, in conjunction with... Figure 3 Verify user credentials in the same way as step 502.

[0050] Users have different levels of permissions. In some embodiments, users can only request data they have attached to the blockchain. In some embodiments, users can only request data within their user category (or a lower-level user category). User levels can be horizontal—that is, even the highest-level user in a branch cannot have access to data attached by users at a horizontal (but lower) user level (e.g., prohibiting the CEO from accessing data entered by HR regarding confidential personnel complaints).

[0051] In step 704, the system defines a search query. If the front-end UI is about to populate a specific domain, the search query can be defined by the front-end UI. Specifically, when data is entered into the relevant domain, a unique code can be appended to that data, which directly corresponds to the search query. Therefore, the search query will only be satisfied by data including the unique code. The search results for the query will have only one result, and the UI elements will retrieve the correct data. In some embodiments, the search query is less specific, and a given user may be using other technologies to search for desired data within the blockchain.

[0052] In step 706, the local node loads the portion of the blockchain that can be decrypted by the user and stores it in plaintext in its local storage. The block loaded into the node's local storage can be a local copy stored on the local disk, or a local copy from an arbitration server or a cloud server. The portion of the blockchain that can be decrypted by a given user is represented based on the unencrypted user ID recorded in each block.

[0053] In step 708, the local node decrypts the block stored in memory. Decryption uses a suitable key held by the local node and authorized by the active user. Blockchain decryption can occur in parallel because each block has its own file. Encryption is not performed at the blockchain breadth (e.g., for every character in the blockchain), but rather on a block-by-block basis.

[0054] In step 710, a search query is applied to the plaintext of the decrypted block. In cases where the blockchain becomes too large for users to store entirely in memory, a search query can be applied to each block as it is decrypted. If the search engine operating with the search query falls below a threshold confidence level or a relevance score on the plaintext of a given block, the search node discards the block from memory. In contrast to the aforementioned techniques, databases typically encrypt or decrypt entirely, rather than on an entry-by-entry basis as described herein. Block-level encryption / decryption is more discrete and enables more efficient data processing. Furthermore, each data element in a database tends to have a larger data size, making it more computationally cumbersome and complex both algorithmically and in terms of individual data elements.

[0055] The threshold confidence score is based on the applied search algorithm. When the search engine uses exact matching (e.g., searching for specific pointer codes), plaintext blocks below the exact match threshold can be discarded. Search engines may utilize keyword search or knowledge graphs, where results are assigned a confidence or relevance rating related to how well a given result relates to the initial keyword search or how well the given result is relevant based on the knowledge graph. Regardless of the search engine style used, a threshold filter is applied to the results in each block. If a given block does not contain any plaintext content with a confidence or relevance score higher than the threshold, there is little reason to retain that data in limited memory. Therefore, plaintext data with low confidence / relevance scores is discarded.

[0056] When a block is discarded, a new block can be read into memory, decrypted, and searched (the search results are either discarded or retained in memory, if applicable). "Discarding" means clearing the relevant space in volatile memory. When a decrypted block is discarded, the original block remains stored in encrypted form in non-volatile memory. However, the plaintext version is no longer present. In step 712, the search results are presented via the front-end UI.

[0057] Figure 6This is a screenshot of the data entry interface and the associated blockchain. In some embodiments, the blockchain data structure is largely invisible to the average user. That is, the connection between the data represented by the domain and the encrypted data in the blockchain data structure does not need to be displayed to the user through the user interface to achieve the functionality of the user interface. For example, the figure depicts the data entry interface 800 of a credit card application. When a user enters data into domain 802 of a credit card application form 804, the data is converted into encrypted blocks 806. In some embodiments, a new block is generated for each domain 802, and a new block is generated each time the user browses and leaves a domain (e.g., clicks on another domain).

[0058] A new block is generated in response to a change in domain 802. Changes in domain 802 can be detected via a user interface application. Specifically, the input interface determines that a change has been made based on data in memory (e.g., keystroke detection or as part of a process of changing data in memory). Alternatively, a change can be detected by encrypting the current data in memory and comparing it with data in an encrypted block in non-volatile storage. If a difference exists, the data has been changed and the node generates a new block.

[0059] In some embodiments, instead of generating a single block for each field 802, a single block is used for the entire form 804. In addition to the user-input data, the viewer application may automatically include pointer data indicating which fields the user-input data is concatenated to.

[0060] On the right side of the diagram, a portion of the blockchain data structure is depicted as block 808. Block 806 shown is updated as users complete a credit card application form on the application's user interface. Notably, the user ID column 810 on the left side of the depiction of the blockchain data structure indicates that a large number of users are simultaneously adding to the blockchain. Each is performing an independent data entry task.

[0061] Figure 7 This is a screenshot of a blockchain viewer application 900, drawn from a blockchain database. The screenshot depicts the viewing page of an embodiment of the blockchain viewer application 900. The depicted pie charts and tables show examples of structured data from a blockchain data structure, representing the distribution of credit card accounts nationwide and over time.

[0062] This example specifically calls upon a large amount of credit card data from customer accounts and displays the data in a single location. The depicted data is automatically retrieved when the page is accessed. Each representation of the data is a graphical transformation of the source data extracted from the relevant portion of the blockchain data structure. If a given user of the application has the necessary permissions to decrypt the relevant portions of the blockchain, these portions are extracted into memory, decrypted, and then applied to the viewer application as input for a function that displays the recorded data in a specific manner.

[0063] The data retrieved from the blockchain data structure is a relatively small set of flat files, making retrieval fast. The functionality and representation of the data are tied to the viewer application itself. Unlike many database software applications, where the stored data includes verbose and complex data processing code (e.g., how data should be typed, how data should be presented, etc.), data processing in flat files is performed by the viewer application itself. Offloading processing from the data itself to the viewer application makes each data element more lightweight and reduces the overall processing time / load for retrieving and presenting data.

[0064] Figure 8 This is a high-level block diagram illustrating an example of a processing device 400 that can represent a system running any of the methods / algorithms described above. The system may include two or more processing devices, such as... Figure 8 These can be interconnected via one or more networks. A network can be referred to as a communication network.

[0065] In the illustrated embodiment, the processing device 400 includes one or more processors 810, digital storage 811, communication devices 812, and one or more input / output (I / O) devices 813, all interconnected via interconnects 814. The interconnects 814 may be or include one or more conductive traces, buses, point-to-point connections, controllers, scanners, adapters, and / or other conventional connection devices. Each processor 810 may be or include, for example, one or more general-purpose programmable microprocessors or microprocessor cores, microcontrollers, application-specific integrated circuits (ASICs), programmable gate arrays, etc., or combinations of such devices. The processors 810 control the overall operation of the processing device 400. The digital storage 811 may be or include one or more physical storage devices, which may be in the form of random access memory (RAM), read-only memory (ROM) (which may be erasable and programmable), flash memory, micro hard disk drives, or other suitable types of storage devices, or combinations of such devices. The digital storage 811 may store data and instructions for configuring the processor 810 to perform operations according to the techniques described above. Communication device 812 may be or include, for example, an Ethernet adapter, a cable modem, a Wi-Fi adapter, a cellular transceiver, a Bluetooth transceiver, or a combination thereof. Depending on the specific nature and purpose of processing device 400, I / O device 813 may include, for example, a display (which may be a touchscreen display), audio speakers, a keyboard, a mouse or other pointing device, a microphone, a camera, etc.

[0066] Unless contrary to physical possibilities, it is anticipated that (i) the above methods / steps can be performed in any order and / or in any combination, and (ii) the components of the corresponding embodiments can be combined in any way.

[0067] The above-described technologies can be implemented through programmable circuits programmed / configured by software and / or firmware, or entirely through dedicated circuits, or a combination of these forms. Such dedicated circuits (if any) can take the form of, for example, one or more application-specific integrated circuits (ASICs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), etc.

[0068] The software or firmware implementing the techniques described herein can be stored on a machine-readable storage medium and can be executed by one or more general-purpose or special-purpose programmable microprocessors. As used herein, the term "machine-readable medium" includes any mechanism that can store information in a machine-accessible form (the machine can be, for example, a computer, network device, cellular phone, personal digital assistant (PDA), manufacturing tool, any device having one or more processors, etc.). For example, machine-accessible media include recordable / non-recordable media (e.g., read-only memory (ROM); random access memory (RAM); disk storage media; optical storage media; flash memory devices, etc.), and so on.

[0069] Physical and functional components associated with processing device 400 (e.g., devices, engines, modules, and data storage libraries, etc.) can be implemented as circuits, firmware, software, other executable instructions, or any combination thereof. For example, functional components can be implemented as dedicated circuits, one or more suitably programmable processors, single-board chips, field-programmable gate arrays, general-purpose computing devices configured by executable instructions, virtual machines configured by executable instructions, cloud computing environments configured by executable instructions, or any combination thereof. For example, the described functional components can be implemented as instructions on tangible storage memory capable of being executed by a processor or other integrated circuit chip (e.g., software, software libraries, application interfaces, etc.). Tangible storage memory can be computer-readable data storage. Tangible storage memory can be volatile or non-volatile memory. In some embodiments, volatile memory can be considered "non-transitory" in the sense that it is not a transient signal. The storage spaces and memories described in the figures can also be implemented using tangible storage memory, including volatile or non-volatile memory.

[0070] Note that, unless otherwise stated above or unless any such embodiments are mutually exclusive in function and / or structure, any and all of the above embodiments may be combined with each other.

[0071] Although the invention has been described with reference to specific exemplary embodiments, it should be understood that the invention is not limited to the described embodiments, but can be practiced with modifications and variations within the spirit and scope of the appended claims. Therefore, the specification and drawings should be considered illustrative rather than restrictive.

Claims

1. A data storage method, comprising: Receive new data via the input interface on the local blockchain node; The new data is stored in plaintext in local memory and simultaneously displayed on the user interface; The new data is written as encrypted ciphertext to local non-volatile storage as a new block on a local copy of the blockchain data structure. The new block includes a flat file whose name is based on a naming convention that identifies the previous block in the block order of the local blockchain node. The name of the new block is generated by an arbitration server in the absence of data in the new block. The local blockchain node includes the ciphertext as a new block with a name derived from the arbitration server. The new block is transmitted to the peer network to be appended to the corresponding blockchain data structure throughout the peer network.

2. The method of claim 1, further comprising: Receive the second new block at the local blockchain node through the peer-to-peer network; as well as The second new block is sorted on the local blockchain node based on the naming convention.

3. The method of claim 2, wherein each block on the local blockchain node further includes a timestamp, and the method further includes: In response to the fact that the new block and the second new block have a matching block order indicated by the naming convention, the local blockchain node uses the timestamp to disambiguate the new block and the second new block in the order of creation; as well as The new block or the second new block is renamed based on the naming convention, which indicates which block was created after the other block.

4. The method of claim 1, further comprising: After being offline for a period of time, the local blockchain node connects to the peer-to-peer network; as well as In response to the connection, the local blockchain node synchronizes a copy of the blockchain data structure with the peer network, starting from the latest block.

5. The method of claim 4, wherein the writing and transmission steps are performed before the synchronization is completed.

6. The method of claim 1, further comprising: A blockchain viewing application is executed on the local blockchain node. The blockchain viewing application is configured to verify a set of user login credentials for a first user, who has a first user key. Determine a subset of the blockchain data structures that can be decrypted by the first user key; Load the subset of the blockchain data structure into the local memory on the local blockchain node; as well as Decrypt the subset of the blockchain in local storage into plaintext.

7. The method of claim 6, further comprising: The physical location of the local blockchain node is determined by the blockchain viewing application, so that the subset of the blockchain data structure that can be decrypted by the first user key depends on whether the physical location of the local blockchain node falls within a predetermined geofence.

8. The method of claim 6, further comprising: The application's graphical user interface receives search queries from the first user via blockchain viewing; Apply the search query to the plaintext; as well as The blockchain viewing application displays the search results from the storage to the first user.

9. The method of claim 6, further comprising: The application displays a graphical user interface, including pointers to data fields, via the blockchain viewer. as well as Data field pointers are filled from the decrypted subset of the blockchain data structure in the local storage.

10. A method for securely retrieving data, comprising: Maintain a copy of the blockchain data structure on the local blockchain node, wherein the blockchain data structure comprises a set of encrypted data blocks linked sequentially based on a naming convention that identifies previous blocks in the sequence, wherein the names of the blocks are generated by an arbitration server, and individual nodes include the ciphertext in the blocks for decryption; A blockchain viewing application is executed on a local blockchain node. The blockchain viewing application is configured to verify a set of user login credentials for a first user, who has a first user key. Determine a subset of the blockchain data structures that can be decrypted by the first user key; Load the subset of the blockchain into the local memory on the local blockchain node; and Decrypt the subset of the blockchain in local storage into plaintext.

11. The method of claim 10, further comprising: The physical location of the local blockchain node is determined by the blockchain viewing application, wherein the subset of the blockchain data structure that can be decrypted by the first user key depends on whether the physical location of the local blockchain node falls within a predetermined geofence.

12. The method of claim 10, further comprising: The application's graphical user interface receives search queries from the first user via blockchain viewing; Apply the search query to the plaintext; as well as The blockchain viewing application displays the search results from the storage to the first user.

13. The method of claim 10, further comprising: The application displays a graphical user interface, including pointers to data fields, via the blockchain viewer. as well as The data field pointer is filled into the decrypted subset of the blockchain data structure in local storage.

14. A data storage system, comprising: Processors implemented on local blockchain nodes; This includes non-volatile data storage of copies of a blockchain data structure, wherein the data elements of the blockchain data structure are encrypted; and The memory contains instructions that, when executed, enable the processor to: Receive new data on the local blockchain node; The new data is stored in plaintext in the memory and simultaneously displayed on the user interface; The new data is encrypted as ciphertext, and the non-volatile data storage is written as a new block into the copy of the blockchain data structure. The new block includes a flat file whose name is based on a naming convention that identifies the previous block in the block order of the local blockchain node. The name of the new block is generated by the arbitration server in the absence of data in the new block. The local blockchain node includes the ciphertext as a new block with a name derived from the arbitration server. The new block is transmitted to the peer network to be appended to the corresponding blockchain data structure throughout the peer network.

15. The system of claim 14, wherein each block on the blockchain data structure includes a flat file that includes a naming convention indicating the block order in the local blockchain node, and the memory further includes instructions that, when executed, cause the processor to: Receive the second new block at the local blockchain node through the peer-to-peer network; and The second new block in the non-volatile data storage is sorted according to the naming convention.

16. The system of claim 15, wherein each block on the local blockchain node further includes a timestamp, and the memory further includes instructions that, when executed, cause the processor to: In response to the fact that the new block and the second new block have a matching block order indicated by the naming convention, the local blockchain node uses the timestamps to disambiguate the new block and the second new block in their creation order; and The new block or the second new block is renamed based on the naming convention, which indicates which block was created after the other block.

17. The system of claim 14, wherein each block on the local blockchain node includes a flat file that includes a naming convention indicating the order of blocks in the local blockchain node, and the memory further includes instructions that, when executed, cause the processor to: After being offline for a period of time, the local blockchain node connects to the peer-to-peer network; and In response to the connection, the local blockchain node synchronizes a copy of the blockchain data structure with the peer network, starting from the latest block.

18. The system of claim 14, wherein the memory further comprises instructions that, when executed, cause the processor to: A blockchain viewing application is executed on the local blockchain node. The blockchain viewing application is configured to verify a set of user login credentials for a first user, who has a first user key. Determine a subset of the blockchain data structures that can be decrypted by the first user key; Load the subset of the blockchain data structure into the memory of the local blockchain node; as well as Decrypt the subset of the blockchain data structure in the memory into plaintext.

19. The system of claim 18, further comprising: A location sensor is configured to determine the physical location of the local blockchain node via GPS or IP tracking, such that the subset of the blockchain data structure decryptable by the first user key depends on whether the physical location of the local blockchain node falls within a predetermined geofence.

20. The system of claim 18, wherein the memory further comprises instructions that, when executed, cause the processor to: The application's graphical user interface receives search queries from the first user via blockchain viewing; Apply the search query to the plaintext; as well as The blockchain viewing application displays the search results in the storage to the first user.

21. The system of claim 18, wherein the memory further comprises instructions that, when executed, cause the processor to: The blockchain viewing application displays a graphical user interface including data field pointers; and The data field pointer is filled with a decrypted subset of the blockchain data structure in the memory.

Images