Updating attribute values in a distributed zero-knowledge database
Multiple devices can update the same attribute of the same node stored in a zero-knowledge database. The node can contain one or more attributes and attribute values. The multiple devices can belong to the same user, or they can belong to different users who all have access to the node and the attributes, for example, via sharing. The disclosed technology determines how the updates to the attribute values are propagated through the system. The attribute values can include information about the user or can include information about the graph, such as incoming or outgoing edges from a node.
1 . A method comprising:
receiving, by a user device, an update request for a version of a node stored in a zero-knowledge database from a server, wherein the user device does not modify the requested version of the node, wherein the node is encrypted and the server cannot decrypt the node or derive any attribute values of the node;
initializing timestamp metadata corresponding to each attribute value and indicating a time when the update request was received at the user device;
determining whether the node has been instantiated and/or initiated on the user device;
in response to the node not being instantiated and/or initiated on the user device:
instantiating and/or initiating the node on the user device;
merging one or more attributes of the node with at least one updated attribute stored in the user device to generate an updated node and assigning the timestamp metadata to each updated attribute value; and
adding the updated node to a queue of updates to be sent to the server; and
in response to the node being instantiated and/or initiated on the user device:
merging the one or more attributes of the node with the at least one updated attribute stored in the user device to generate the updated node by:
determining which attributes in the node have been updated;
assigning the timestamp metadata to each updated attribute value; and
preserving existing timestamp metadata for attributes that have not been updated; and
adding the updated node to the queue of updates to be sent to the server.
2 . The method of claim 1 , wherein the one or more attributes of the node are derived by decrypting the node using the user device.
3 . The method of claim 1 , wherein the node stored in the zero-knowledge database is accessible by a plurality of devices,
wherein the user device is a device of the plurality of devices.
4 . The method of claim 3 , further comprising receiving, by the user device, a version number of the node form the server.
5 . The method of claim 4 , further comprising:
adding the version number along with the updated node to the queue of updates to be sent to the server; and
comparing, by the server, the version number against a current version number of the node that is stored on the server.
6 . The method of claim 5 , further comprising:
for the version number being determined as identical to the current version number, storing the updated node in the zero-knowledge database and incrementing the current version number.
7 . The method of claim 6 , further comprising:
sending, by the server, an incremented version number to the user device.
8 . The method of claim 6 , further comprising:
for the updated node being successfully stored in the zero-knowledge database, incrementing, by the user device, a local version number that corresponds to the version number.
9 . The method of claim 6 , further comprising:
for the version number being determined as lower than the current version number, preventing, by the server, storing of the updated node on the zero-knowledge database.
10 . The method of claim 5 , wherein the version number and the current version number are not encrypted.
11 . The method of claim 1 , further comprising:
determining whether the updated node was successfully stored in the zero-knowledge database.
12 . The method of claim 11 , further comprising:
for the updated node being determined as not successfully stored in the zero-knowledge database, determining whether the node was locked.
13 . The method of claim 12 , wherein a node is locked if it is being updated.
14 . The method of claim 12 , further comprising:
for the node being determined as locked, keeping the updated node in the queue of updates for processing.
15 . The method of claim 14 , further comprising:
for the node being determined as not locked, comparing a version number associated with the updated node against a current version number of the node that is stored on the server.
16 . The method of claim 15 , further comprising:
for the version number being determined as lower than the current version number, sending, by the server, a current version of the node stored in the zero-knowledge database and the current version number to the user device;
decrypting, by the user device, the current version of the node to generate a decrypted current version of the node; and
merging, by the user device, the updated node with the decrypted current version of the node to derive a merged node.
17 . The method of claim 16 , further comprising:
adding, by the user device, the merged node to the queue of updates to be sent to the server.
18 . A system comprising:
a server; and
one or more processors in communication with the server, the one or more processors are configured to:
receive an update request for a version of a node stored in a zero-knowledge database from the server, wherein the one or more processors do not modify the requested version of the node, wherein the node is encrypted and the server cannot decrypt the node or derive any attribute values of the node;
initialize timestamp metadata indicating a time when the update request was received, wherein each attribute value in the node has a corresponding timestamp metadata;
receive the node and an associated version number;
determine whether the node has been instantiated and/or initiated by the one or more processors;
in response to the node not being instantiated and/or initiated by the one or more processors:
instantiate and/or initiate the node;
merging one or more attributes of the node with at least one updated attribute stored in a memory coupled to the one or more processors to generate an updated node by assigning the timestamp metadata to each updated attribute value; and
adding the updated node and the version number to a queue of updates to be sent to the server; and
in response to the node being instantiated and/or initiated by the one or more processors:
merge the one or more attributes of the node with the at least one updated attribute stored in the memory to generate the updated node by:
determining which attributes in the node have been updated;
assigning the timestamp metadata to each updated attribute value; and
preserving existing timestamp metadata for attributes that have not been updated; and
add the updated node and the version number to the queue of updates to be sent to the server,
wherein the version number as received by the server is compared against a current version number of the node that is stored on the server,
wherein for the version number being determined as identical to the current version number, storing the updated node in the zero-knowledge database and incrementing the current version number.
19 . The system of claim 18 , wherein for the version number being determined as lower than the current version number, preventing, by the server, storing of the updated node on the zero-knowledge database.