Method and system for synchronizing and controlling state in a computer-implemented environment - Patents.com

Abstract

In the present invention, the method broadcasts the presence of a first actor (O1) in a zone of a domain (D) having a number of zones (Z) which are physical entities represented by spatial data which can be represented as virtual zones or as entities in a database. The zones have functions and / or variables and / or are controlled by a program which represents the zone. The domain (D) may be a distributed data structure and may be configured on a distributed ledger. The method comprises a step of broadcasting the presence of the first actor (O1) in the zone (Z), the first actor (O1) sending at least one transmission to at least one other actor (O2) in the domain, the transmission including data enabling at least one other actor (O2) to determine the proximity of the first actor with respect to the zone (Z). The domain may be a network and may be used to define an environment or a domain, such as a warehouse.

Description

[Technical field]

[0001] The present disclosure generally relates to methods and systems for enabling secure communication between multiple actors (e.g., users) operating within a domain having a zone. Such a domain may include computer implementation environments, including, but not limited to, virtual machines (VMs), threads of execution and / or processes, or network enclaves. Advantageously, embodiments of the present disclosure may be used to synchronize, monitor, and control the behavior of actors within a zone, leading to many technical advantages, such as ensuring state consistency and enhancing security.

[0002] According to one or more embodiments, an actor can monitor a domain or a portion thereof, an actor can determine the presence of another actor, and an actor can participate in and interact with the zone. The domain and its portions can represent real-world and / or digital assets. The assets can have functions and / or variables. The embodiments provide an enhanced cryptographically secure solution for the processing of sensitive or secret data in the domain, providing a platform and / or underlying mechanism that can be advantageously utilized by a variety of technical implementations. The present invention is particularly suited for use in blockchain-related technologies, but is not limited thereto. [Background technology]

[0003] The presence, actions, and associated data of users (actors) in a computer system need to be controlled and / or monitored to maintain the consistency and integrity of the state of the data in the system. State consistency is essential to ensure that there is one version of reality that all users of the system can trust. For example, with respect to graph databases and distributed systems, it is known that multiple users performing actions at different times can result in duplicate or contradictory results. Avoiding inconsistencies and ensuring synchronization of data and state is particularly challenging in distributed networks and systems, since users typically act independently of one another and can dynamically come and go as they use and navigate the system. In addition to mitigating duplication, implementing and controlling a system of record and a means of tracking changes of actors in the system may require, or at least benefit from, a persistent and immutable record of functions and variable changes performed in or by entities. The present disclosure aims to provide techniques that at least mitigate or eliminate these technical challenges. Summary of the Invention [Means for solving the problem]

[0004] The methods and systems herein generally support communication from at least one actor in a given domain to all other actors, and between two or more actors occupying the same space / zone within that domain. Domains and zones within domains are preferably provided with functions and / or attributes. The methods disclosed herein can support monitoring and / or synchronization of changes to functions and / or attributes performed by multiple actors in the same zone.

[0005] Consider an exemplary, non-limiting scenario in which multiple actors (e.g., users) are active within a computer-based system that includes multiple environments. These environments consist of, for example, one or more of virtual machines (VMs), code segments, threads, processes, or "boxes." In other examples, environments may consist of or have access to segments of a database, or data storage resources or other resources. In accordance with a preferred embodiment, such environments may be modeled as rooms, tables, or other data structures. A room may be referred to as a "zone" within a broader domain / system.

[0006] Preferably, at a particular point in time, one or more actors can be located in a given environment or part of it (i.e., active in or belonging to / affiliated with the environment), but a given actor can only be in one room at any one time. In some cases, an actor is considered to be active or located in an environment when it desires to perform an action, such as, for example, accessing data and / or writing data to a resource associated with that environment. In other examples, an actor may be considered to be in a room when it makes its presence known to other actors. Actors can enter and leave rooms.

[0007] A "room" consists of one or more computing resources. These resources consist of hardware, software, and / or firmware. Thus, each room can, for example, send and receive communications, store data (state), provide data, etc. A room may have a controller that authorizes and / or specifies the functions associated with that room. A room and / or its controller may be subordinate to a domain / controller.

[0008] An actor may want to perform certain functions or actions with respect to the room that it is in, such as writing data to a storage resource associated with the room. As a result, other actors in the same room need to be aware of the actor's presence. Also, other actors may need to know what data and / or actions the actor is trying to create. Actors in a room need to: 1. Talk to and participate with each other; 2. Lock the data they manipulate to prevent inconsistencies; and 3. Interact with resources associated with the room.

[0009] In a preferred embodiment, the n data rooms in the system are 0 , R 1 , ... R n-1 Each room in the system can be written as a seed:{r 0 , r 1 , ... r n-1} can be described or defined using a random function that generates r i With knowledge of R i You can unlock structures and gain knowledge.

[0010] Preferably, each data room has a key {K 0 , K 1 , ... K n-1}. These may be linked using, for example, a hash chain, or a key generation algorithm where the subkeys can be derived from the master key. In the preferred embodiment, i A user of key k i Data can be encrypted and sent using the same R i All users of key k i You can use the key k i allows actors in a room to see and / or access the data and resources in the room. This allows the room R iThe state of a room can be read by actors in that room, but not by other actors.

[0011] The key for a given room may be updated over time or when a triggering event occurs, such as when a user changes rooms.

[0012] Preferably, a bit commit can be set and used for each room, as described in more detail below.

[0013] To aid in understanding embodiments of the present disclosure and to show how such embodiments may be carried into effect, reference will now be made, by way of example, to the accompanying drawings in which: [Brief description of the drawings]

[0014] [Figure 1] FIG. 1 is a schematic block diagram of a system for implementing a blockchain. [Diagram 2] FIG. 1 illustrates generally some examples of transactions that may be recorded on a blockchain. [Figure 3A] FIG. 2 is a schematic block diagram of an embodiment of a client. [Figure 3B] FIG. 3B is a schematic mock-up diagram of an exemplary user interface that may be presented by an embodiment of the client of FIG. 3A. [Figure 4] FIG. 2 is a schematic block diagram of node software for processing transactions. [Diagram 5] FIG. 1 is a schematic block diagram illustrating domains, sub-domains, zones, and sub-zones which represent entities or locations with which an operator communicates and functions. [Figure 6] 1 is a flow chart illustrating communication between two operators. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0015] According to one aspect disclosed herein, a method and corresponding system are provided for securely communicating or indicating the presence of a first actor of / within a computing environment implemented as a component of a computer-based system / environment. Additionally or alternatively, the present disclosure may be described as providing an enhanced computer-implemented solution for broadcasting messages to or communicating between actors (users) in a computer system to secure collaboration and interaction between actors. An actor may be a human, a machine-based entity, or a computational entity such as an oracle or a bot. The terms "actor," "operator," "user," "entity," or "party" may be used interchangeably herein.

[0016] The term "presence" may be used to describe an actor's relationship to the domain and / or its location / position within the domain. In physical form, an actor may "be" in the domain or a part of it. However, a virtual actor may not be physically present in the domain or a part of it, but may "be" or have a "presence" by being relevant. In other words, a virtual entity may be present in the domain by being operationally active or associated with the domain, and thus may be operationally or currently active, e.g., in service or performing an action, or may be active or passive in the domain. The term "presence" may be applied to virtual entities as they may have relevance or visibility, i.e., relationships, to other actors when they are in the same domain / zone or close to each other.

[0017] A domain is preferably composed of a zone or multiple zones. A zone may be defined as a particular area, region, or part of a domain. For a given zone, one or more boundaries may be defined or calculated. A zone may be referred to as a "sub-zone." A zone may be composed of one or more additional (sub)zones, and a domain may have a hierarchy of zones. For brevity and ease of reference, the term "zone" is used. In the above example, the term "room" is used. In the following example, the term "zone" is used instead.

[0018] A zone within a given domain may be associated with one or more attributes that relate to or determine the state of that zone. For example, if a domain is a leisure center consisting of subzones "gym", "pool" and "dance studio", the attribute of the "pool" subzone may be "has showers" and the attribute of "gym" may be "has treadmills". In an example of a virtual domain, the domain is a gaming environment, where actors (players / avatars) may move between different rooms, levels, worlds, etc. (zones) within the virtual environment. Consider another example, including simulated environments such as medical simulations or aircraft simulators. In some examples, the zones are virtual machines or code segments running on a computer, or databases, etc.

[0019] Additionally or alternatively, a zone may be associated with one or more functions or capabilities that may be performed by an actor associated with the zone. For example, an actor actively associated with the "pool" zone of a leisure center may perform the "start shower" action, and an actor actively associated with the "gym" may perform the "change treadmill speed" action. A player of a game may move from one room to another in a building and pick up designated items in each room. Each zone may be associated with a set of rules that govern how actors in that room may behave and how they may use any resources associated with that zone. Attributes associated with a domain and / or its one or more zones are preferably predetermined by an administrator or controller, in the sense that they cannot be changed by actors in the domain. Similarly, functions associated with a zone may not be determined or changed by an actor. An actor may be considered "active" in a domain or zone if the actor is actively involved in or associated with the domain / zone. Each domain / zone has its own security / authentication requirements that an actor must meet to become an active member. These are described in more detail below.

[0020] The methods and systems herein generally support communication from at least one actor in a domain to all other actors, and between two or more actors occupying the same zone in the domain. The domain and the zones in the domain are provided with functions and / or attributes. The methods herein can support monitoring and / or performing synchronization of changes to functions and / or attributes performed by multiple operators in the same zone. The system can be an application domain. The application domain can function as a mechanism or process, for example, by implementing executed software applications that are separated / isolated from each other.

[0021] A domain may be a logical or technological space / environment defined based on or in accordance with the implementation of an embodiment of the present disclosure. In some preferred embodiments, a domain may model a real-world entity or location, such as a building, such as a shopping center, manufacturing facility, or warehouse, that is represented digitally. The domain, its zones, any features and / or attributes may be represented by a computer-based system of record or database, such as a distributed database or a blockchain ledger. Alternatively, the domain, its zones, any features and / or attributes may be digital and may represent, by way of example, an online game, a spreadsheet, or a graph database. By way of example, the domain and / or zones may be represented as tokenized resources or entities. The features of the domain and / or each zone may implement rules that determine behavior.

[0022] Examples herein describe technical solutions that enable multiple actors to perform actions on or within a domain and / or a zone of a domain. Actions include at least one of controlling, influencing, or directing entities in the system, e.g., actors operating in the domain or a portion thereof. Methods herein allow for maintaining consistency of the state of the domain by allowing actors to communicate securely and / or privately. In this way, actors within or close to a zone can cooperate to avoid duplication and support eventual consistency.

[0023] Further, a control and / or recording system is disclosed for controlling and / or monitoring a system representing a domain (D) to track functions performed and / or changes to variables of zones in the system, which may benefit from a permanent and immutable record of changes to variables of the zones, functions performed by operators in the zones, or functions performed by the zones. A zone may be a technical environment that constitutes part of a larger technical environment. In other words, a zone may be a sub-environment that forms part or a component of a system and / or a super-environment / wider environment.

[0024] The method herein may be applied to the following scenarios, by way of non-limiting examples: two players in an online chess game, two data analysts wanting to update the same cell in a spreadsheet, two or more autonomous robots accessing the same storage bin in a warehouse, a safety system that warns when two vehicles, e.g., airplanes, approach each other, etc. The method includes determining the location of an electronic tag worn by a person within a building or complex having zones relative to a particular zone and / or another tag worn by another person. When applied to determining the location of an electronic tag worn by a person, the method may support ensuring that criminals and / or parolees are not near restricted areas such as a victim's home or a liquor store.

[0025] Synchronization - Overview FIG. 5 shows the O A , O B , O C , O D , O E , and O F Several operators (actors) O n The diagram shows a schematic of a domain, where an operator can be a user or other type of actor, e.g., a human, a machine-based entity, or a computational entity such as an oracle or a bot. The domain includes a sD 1 , s.D. 2 , and s.D. 3The subdomain sDn is labeled as Z. 1 From Z 5 There are zones Zn labeled as sZ 1 From sZ 4 A domain may further be occupied by parties with read-only or view-only access to the status and / or behavior of the domain and its zones. These parties are referred to as viewers V 1 From V 4 The domain D is shown for illustrative purposes only and is not intended to limit the invention. The number of subdomains, zones, and subzones may vary depending on the application and / or implementation of the invention.

[0026] In the digital realm, a zone is typically a program or data room that is functional and / or contains variables. 1 ,Z 2 ,Z 3 ... Z N-1} are sometimes called virtual rooms, spaces, data structures, or environments implemented using the . These virtual rooms can be objects in a program that model the entities to be controlled. Models have functionality implemented by methods, functions, and procedures that can be called at run time, and variables that provide static or dynamic state.

[0027] A subzone is denoted by Z' and a subsubzone is denoted by Z''. A zone is a set of the corresponding seeds {z 1 ,z 2 ,z 3 , ...z N-1}. 1 By knowing,(i) we can “unlock” a zone and,then,Z, 1 Top or Zone Z 1 (ii) performing a function within Z 1 Each room can read the contents of the corresponding "control" key {k 1 ,k2 ,k 3 ...k N-1 Possession of the control key allows the owner to lock, unlock, modify, or encrypt the zone or any part of it.

[0028] In the following example, two users, nominally called Alice and Bob, A and O B Two actors, D and D, are referenced and intend to perform functions in a zone in the domain. In practice, Alice and Bob denote the first and second actors, respectively. In the examples herein, Alice and Bob are described as humans performing functions and interacting with the domain D, but it is actors, e.g., computational entities, that perform functions providing at least one of communication, synchronization, validation, authentication, and security. For example, a zone can represent a storage bay in a warehouse, a location in a game that may be digital and online, or a cell in a spreadsheet. When Alice and Bob are in the same zone or wish to perform functions related to the zone, they can be aware of each other's presence and / or collaborate. Similarly, actors, such as Alice and Bob, do not have information (e.g., location) about other actors in order to maintain privacy.

[0029] The term “zone” is a generic term used below to denote a separable / defined portion of domain D, and in some embodiments, the smallest divisible region of domain D, denoted as sZ in FIG. 1 In view of the teachings herein, it can be appreciated that the present invention enables a first actor to determine the presence and / or absence of a second actor in a zone, subzone, subdomain, or the domain itself. The level of granularity and awareness of "presence" or "absence," as well as "active" and "inactive" status, can be configured depending on the implementation.

[0030] An actor first accesses Domain D and / or a digital representation of the domain through a login or similar security process where the operator / actor is verified and / or authenticated depending on the implementation. Upon accessing the domain, each actor is given a unique label that allows the domain and / or other actors to identify and / or address the actor. This label is referred to herein as a tag. In the case of a biological actor, the tag is physically worn or attached and acts as the actor that holds the label. The tag can be configured according to the usage scenario and can exist in at least one of digital form and hardware, in the case of digital form, the tag exists in a program running on a device having memory that stores the tag and is used during communication with other actors, in the case of hardware, the device stores the tag in memory and / or in a radio frequency identification (RFID) device, the device can be attached to a robotic module or a wearable such as a wristband. The device and / or program that holds the tag is configured to communicate with (i) the domain and several zones contained in the domain, and (ii) each of the actors in the domain. The label assigned to an actor is unique to that actor. A label may be dynamically assigned each time an actor enters a domain or may be static and retained by the actor. A label may be an alphanumeric code and may be represented in digital or physical form such as a QR code. A label may be a public address associated with a cryptographic key pair. A label may be a public key value derived from a temporary private key. If the label is associated with a biological actor, the label may be derived at least in part from or include biometric data.

[0031] Each domain D and each subdomain, zone, and subzone has an identifier S that distinguishes it from other zones in the domain and allows an actor to determine its location within the domain, i.e., which zone it is in. A has.

[0032] An actor can only use identifier S when it is in the zone. A As a non-limiting example, the identifier may be obtained by at least one of reading a code, such as a barcode, displayed within the zone and readable using a viewing system from a physical marking or digital display, detecting a digital signal using radio frequency (e.g., RFID), or the identifier may be obtained by Alice communicating with Zone Z, which has the ability to manage its identifiers and their updates, and Alice may receive and store the identifier. Zone Z's identifier may be fixed or dynamic. If dynamic, it may be changed, replaced, or updated in other ways. The trigger for the update may be at least one of the satisfaction of an event or condition, such as a new actor entering the zone, an actor leaving the zone, or the zone being vacant for a period of time. In other examples, the update may be initiated by a controller, such as a domain or zone administrator.

[0033] Zones Z within a domain or subdomain sD can be nested. The example in Figure 5 shows an example of a subzone sZ 1 Zone Z 1 It is co-located with the other three sub-zones in Zone Z. 1 is co-located with the other two zones in subdomain sD1 and is co-located with the other two zones in subdomain sD 1 is co-located within domain D with two further sub-domains. For example, a cell in a table in a spreadsheet such as Excel (RTM) may be part of a row or column, and the table may be in one of several tabs within a particular file. Similarly, a bin in a warehouse may be located in a particular row at a particular level of a sub-area within the warehouse. A zone has an identifier S that distinguishes it from other zones in the domain. A , and at least one additional identifier that identifies the location of the zone relative to other zones. In other words, the additional identifier may be a neighboring zone (e.g., sZ 1 is SZ 2 next to it), the zone in which it is located (for example, sZ 1 is Z 1the subdomain in which it is located (for example, sZ 1 sD 1 A zone can indicate at least one identifier of a domain (such as a strict zone, a strict domain name, or a strict domain name). A zone tells actors their relative location within a domain, allowing them to see who is in the same zone and who is in an adjacent zone.

[0034] The control system of domain D can determine the relative locations of all actors, for example the relative proximity of at least one actor to another, which can be important if one actor is prohibited from being in the same zone or within a given proximity range of another actor.

[0035] The control system monitors and / or observes the actions performed by the actors, monitors and / or observes the functions or operations performed by the zones, collates the acquired data and communicates it to the viewer V N The SEC may provide at least one of the following: read-only or view-only access to the status and / or behavior of the domain and its zones. View-only access is the viewer V in Figure 5. 1 and V 2 For example, V 3 View-only access means that the functionality provided by the domain is local, e.g., 1 This may be permitted when the forum supports online gaming, such as when Alice and Bob are playing a game of chess.

[0036] Domain D and each of the separated areas, e.g., sub-domain sD, zone Z, and sub-zone sZ, are provided with the functionality and / or attributes necessary for the implementation of the present invention. Zone Z can be digitally represented as a program, which runs on a machine with a processor and associated memory. The machine can be configured locally to the zone or can be controlled centrally, e.g., at a control center for domain D. In one example, the zones can be storage bins in a warehouse, which can display an identifier for the zone, which can be read by a robot configured to add or remove items from the bin. In another example, the zones can represent an online game, e.g., chess, where the program not only provides the identifiers for the zones, but also controls the rules and protocols of the game, and the inventory and position of the pieces in the game.

[0037] Synchronization - Communication In the context, Alice enters a domain with multiple zones. Alice may be a robot configured to enter and work in a warehouse, placing and retrieving items from a storage bin. Alternatively, Alice may be a human wearing a tag that functions as a mobile communication device, such as a smart tag, such as a smart watch. Still alternatively, Alice may be a player of an online chess game that she has joined, for example, via a user interface (UI) 500. Regardless of whether Alice enters a physical space or a digital domain, she may not be able to know who else is in the domain or who she can communicate with, until contact is established, for example for security reasons. Furthermore, if Alice is a robot and wants to change the inventory of the storage bin, she needs to cooperate with other robots that intend to do the same.

[0038] If another actor, say Bob, is in the same zone, Alice needs to synchronize the state of Zone Z and commit the actions she performs to prevent duplicate actions and / or cheating. Synchronization is especially important when certainty of the actions performed is required, for example when Alice and Bob are playing an online game such as chess or poker. The examples herein allow actors to perform functions and interact in an untrusted system, and avoid inconsistencies in data and state within the system.

[0039] Figure 6 shows, by way of example, the first actor (in this case "Alice") that exists or intends to function within a zone (Z) of a domain (D) with multiple zones (Z) similar to that of Figure 5. A ) is broadcasted. In one example, Alice broadcasts the existence of an identifier Z A sZ with 1 Note that the steps describe that Alice or Bob perform the actions. However, in reality, Alice and / or Bob may be computer-based resources that can perform the steps with an operating system, host, program, or device that executes the steps and functions. This allows the actions to be performed automatically. Note that domains and parts thereof may be software-implemented entities that can be implemented in hardware and / or executed as applications.

[0040] At S608, Alice creates a random string of bits, e.g., generates a temporary key, and stores it as a secret S X Additionally, Alice establishes an identifier Z associated with the zone. A, which may be obtained from the zone itself. In some examples, the identifier may be data obtained using a physical device, such as a QR code or barcode that can be read from at least one of a fixed display, a digital display, or an RFID. In other embodiments, the identifier may be stored, requested, accessed, and received by electronic means rather than physical capture using a scanner, camera, etc. Additionally or alternatively, the identifier may be obtained by Alice communicating with Zone Z to obtain and store the identifier.

[0041] In S610, Alice reveals her secret X For example, Alice can perform a hash operation on her secret, i.e., h(S X ) and calculate the value H(S X ), which Alice can send to all actors in domain D, and this can be done via each zone Z in the domain.

[0042] In S612, Bob, who is in the same zone Z as Alice, receives and stores Alice's commitment. Since Bob is in the same zone as Alice, he receives the same identifier Z from the zone. A Get the.

[0043] At S614, Alice prepares and broadcasts at least one transmission to all actors in the domain and / or to all zones Z in the domain. Each actor receives transmissions from Alice directly and / or via zone Z. The transmissions serve to communicate by sending information, e.g., via messages or data packets, where this information includes data that allows Bob to determine Alice's presence with respect to zone Z. Using the information (e.g., data) in the transmission from Alice, Bob can compare these data with the data of the zone. The data includes a zone identifier Z A or any derivative thereof. If Bob is in the same disjoint area of ​​domain D, i.e., Bob is in the same zone as Alice and has the same zone identifier (say ZA ), Bob can determine that he is in the same zone as Alice.

[0044] Additionally or alternatively, the data in Alice's transmission includes an identifier for any one of the separable parts of domain D. In this way, the identifier can indicate to another actor in which part of the domain it is present, so the level of granularity and awareness of presence or absence can be configured depending on the implementation. Using Figure 5 as an example, let us consider the case where Alice O A sZ 1 If sZ exists, Alice can determine whether she is 1 , Z 1 , and s.D. 1 A transmission can be sent containing data indicating the presence of sZ. 1 , Z 1 , and s.D. 1 Alternatively, three separate transmissions could be made for each zone. F (Frankie) is a subdomain sD 1 and Alice has broadcast at least one transmission indicating her presence to Frankie (this is because Alice 1 , Z 1 , and s.D. 1 From the data in the transmission, Frankie can only determine that Alice is in the same subdomain, but cannot determine which zone or subzone Alice occupies.

[0045] In S616, Bob or Frankie determine Alice's presence in the same isolated area by reading the transmission. They can send back a verification, which they can provide because they have access to the same identifier of the isolated area they are in. Specifically, Alice sends a transmission that allows Bob to verify Alice's presence and / or absence in the isolated area, and Bob can send a response verifying his location within the domain.

[0046] In S618, Alice receives Bob's verification. Then, in S620, Alice sends her secret S X and Bob can verify it at S622.

[0047] Of course, Bob can repeat the same procedure as Alice, making transmissions that allow each to determine their presence. Different zones consist of different functions that determine the rules and protocols that actors must follow.

[0048] In the example of Figure 6, the data in Alice’s transmission allows someone in the isolation area to determine Alice’s presence, and Alice uses the identifier in the data in her transmission as a secret S X i.e., secret S X = Identifier Z A As shown in Figure 6, Alice sends a commitment to Bob using her secret in S610. In step S614, Alice creates a transmission that includes data that only Bob, or another actor in the same isolation area as Alice, can use to determine Alice's presence. Bob can also determine Alice's presence because he knows the identifier.

[0049] In the example of FIG. 6, at least two different transmissions are made: one transmission contains an identifier (S X ,Z A ) and the binary value '1', i.e. S X 1, which is either (i) sent to all actors in the domain or (ii) sent to the zone where Alice is located, and another transmission is X ,Z A ) and the binary value '0', i.e. S X 0, which is either (i) sent to all actors in the domain or (ii) sent to zones where Alice is not present. X The binary value concatenated with may be referred to as an indicator.

[0050] The concatenated values ​​of the identifier and indicator are used to create a commitment, which forms part of the data for transmission S614 and, in this example, is a hash value of the concatenation, e.g., h(S X |1) and h(S X 0). Each of the other actors, including Bob, responds in step S616 with a corresponding response, e.g., H(S X |1) and H(S X Alice can reply with confirmation of her location by sending H(S X |1) and H(S X |0), then S620 X to Bob so that Bob can verify in S622 the previous commitment made by Alice in S610.

[0051] The use of at least a second transmission indicating that Alice is not within the zone can avoid Alice or other actors revealing their location to anyone other than those in the same zone.

[0052] In the example of Figure 6, identifier S X is concatenated with an indicator that is a binary value. An alternative to concatenating the identifier and the indicator may be, for example, an XOR operation. Furthermore, the indicator is not limited to a non-binary value. For example, the identifier of a zone may be concatenated with an indicator that informs the recipient of at least one of the first actor's access level, presence, and / or intent with respect to at least one of the zone (Z), domain (D), subdomain (sD), and subzone (sZ).

[0053] In general, at least one transmission and / or the second transmission includes an operation on the identifier and the indicator, which may be, for example, a hash of the concatenation, i.e., h(R 1 |p) and / or h(R 1 |q), where h represents the hash function applied to the transmission, and R 1is an identifier of the zone (Z), domain (D), subdomain (sD), or subzone (sZ) in which the first actor resides, and |p and |q are indicators concatenated to the zone identifier that provide additional information to another actor and inform the recipient of at least one of the first actor's access level, presence, and / or purpose with respect to the zone.

[0054] As mentioned above, the identifier may be unique for each separate area, such as a zone (Z), a sub-domain (sD), a sub-zone (sZ), etc., and may be generated by the functional zone. The identifier may be derived from a master key and / or updated at predetermined intervals.

[0055] Domain - Implementation Example Examples herein apply to domains (D), e.g., having separate areas with their own functions and / or operating according to their own rules and protocols. A domain or a portion thereof may be at least one of a physical entity represented by spatial or geospatial data (e.g., a warehouse), representable as a virtual zone in a virtual domain (e.g., a digital representation of a warehouse and / or its contents), and representable as entries in a database or data table (e.g., a bin in a warehouse can be documented by an entry in a spreadsheet). Examples herein are provided to illustrate the functionality of the systems and methods taught herein, and the claimed invention is not limited thereto.

[0056] In an example where Alice and Bob are robots operating to store or collect items from a segregated area such as a storage bin in a warehouse, before changing the quantity of an item, the robot or each robot must determine whether the storage bin is the only one with that item. With reference to FIG. 6, Alice can create a commitment S608 and / or broadcast a transmission S614, where data is securely exchanged and only robots in the same storage bin are aware of Alice's presence. Other robots, such as Bob, perform the same action to determine that Alice is present. Each robot can then communicate to commit to adding or removing items from the storage bin to prevent errors in inventory counts. By way of example, the functionality of the storage bin can be represented as a program that controls tokenized resources. Alice and Bob can establish secure communications between themselves and / or with other robots operating to change the inventory in the storage bin. Additionally or alternatively, the actors can establish secure communication channels with programs to interact with the inventory in the storage bin.

[0057] In the example of Alice and Bob playing a game of chess, the domain may be an online gaming platform to which Alice and Bob subscribe. Referring to FIG. 5, Alice and Bob are assigned a board in an isolated area sZ1, where the game is controlled by a program. The program can keep track of the game by updating the status of tokenized resources. Any actor with access to the platform can view a game, or a group of games in a larger isolated area, e.g., zone Z. 1 Viewer V 3 sZ 1 From sZ 4 We can observe four games in the area labeled . The zones are separated by a seed {z 1 ,z 2 ,z 3 ...z N-1}. Only those who are in the game are allowed to perform functions such as unlocking zones and moving chess pieces, and this permission is granted by obtaining the corresponding "control" key {k 1 ,k 2 ,k 3 ...k N-1}. Alice and Bob have accessed the game platform and have chosen to play a game of chess, but are otherwise unaware of the presence of their opponent. Using one or more steps described herein, Alice and Bob perform at least one of the following: verify the presence of the opponent, e.g., so that one player can know that the other is still playing; exchange commitments, e.g., to determine that a move has been made and completed; establish a new shared secret, e.g., using a zone identifier, so that players can communicate securely without exchanging secret keys, e.g., as described in WO 2017 / 145016, which is incorporated by reference herein in its entirety. The program controlling the game, and / or Alice and Bob, can interact with a token that represents the game and records board statistics and move history in one or more transactions.

[0058] There is a similarity between the game of chess and the control of a spreadsheet or other database with organized data or values ​​(e.g., cells in an Excel (RTM) spreadsheet) that can hold values ​​entered directly or derived from formulas based on the values ​​of other cells. Again, actors gain access to a domain, e.g., a database, and using one or more steps described herein, Alice and Bob do at least one of the following: verify the other's presence, e.g., so that one actor can know if the other actor intends to modify the content of the call; exchange commitments, e.g., to ensure that changes made to cell values ​​and / or formulas are non-duplicative and error-free; establish a new shared secret, e.g., using the cell's identifier, which may be necessary if the purpose of the changes is confidential and security must be maintained.

[0059] In yet another non-limiting example, the domain is either a school, a prison, or a leisure center, and the actor wears a personal tag, such as a smartwatch. The tag or smartwatch is an electronic device configured to implement the methods herein alone or in combination with a domain control system. The domain may be implemented at any scale, such as a road network or a city. The tag may operate autonomously to implement the methods herein, and may, by way of example, determine at least which other actors are in the same zone and / or nearby. The tag may provide an audio and / or haptic alert, for example, if the actor is not allowed to enter the zone and / or if the tag determines that the first actor is prohibited from being with another actor, for example by a restraining order. The tag may determine the functions the actor may perform in collaboration with another actor and / or within the zone itself.

[0060] A domain may include a control system capable of monitoring and determining at least one of the number of actors in a given area and the relative proximity of the actors to each other. The control system may take at least one action, e.g., via communication with tags and / or zones, such as warning actors that there are too many actors in one isolated area (e.g., a zone) or restricting access, e.g., by preventing entry through an electronically secured door. As alluded to above, the functionality and / or variables of the zones may be controlled using tokenized resources, e.g., UTXOs, which reside on a blockchain. The domain and the zones therein are controlled by at least one program running on a machine, enabling an actor to determine the presence, absence, and relative proximity of another actor. The or each program may be implemented in at least one distributed data structure and configured on a distributed ledger, e.g., a blockchain ledger.

[0061] Domain - Security Enhancement How to establish secure communication between actors using a shared secret is described above with reference to WO 2017 / 145016. It is noted that the transmission can be further strengthened by communicating a secret, as disclosed in WO 2019 / 220298, which is incorporated herein by reference in its entirety.

[0062] conclusion Other variations or uses of the disclosed techniques will be apparent to those of ordinary skill in the art once they have read the disclosure herein, and the scope of the disclosure is not limited by the described embodiments, but only by the scope of the appended claims.

[0063] For example, some embodiments described above are described with respect to the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin nodes 104. However, it will be understood that the Bitcoin blockchain is one particular example of the blockchain 150, and the above description is generally applicable to any blockchain. That is, the present invention is not limited to the Bitcoin blockchain. More generally, references to the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin nodes 104 described above may be replaced with references to the blockchain network 106, the blockchain 150, and the blockchain nodes 104, respectively. The blockchains, blockchain networks, and / or blockchain nodes may share some or all of the described characteristics of the Bitcoin blockchain 150, the Bitcoin network 106, and the Bitcoin nodes 104 described above.

[0064] In a preferred embodiment of the present invention, the blockchain network 106 is the Bitcoin network, and the Bitcoin nodes 104 perform at least all of the aforementioned functions of creating, publishing, propagating, and storing blocks 151 in the blockchain 150. It is not excluded that there may be other network entities (or network elements) that perform only one or some, but not all, of these functions. That is, network entities may perform the functions of propagating and / or storing blocks without creating and publishing them (note that these entities are not considered to be nodes of the preferred Bitcoin network 106).

[0065] In other embodiments of the invention, the blockchain network 106 may not be the Bitcoin network. These embodiments do not preclude a node from performing at least one or some, but not all, of the functions of creating, publishing, propagating, and storing blocks 151 of the blockchain 150. For example, in other blockchain networks, a "node" may be used to refer to a network entity that is configured to create and publish blocks 151, but is configured not to store and / or propagate those blocks 151 to other nodes.

[0066] More generally, references above to the term "Bitcoin node" 104 may be replaced with the term "network entity" or "network element," with such entity / element configured to perform some or all of the roles of creating, publishing, propagating, and storing blocks. The functionality of such network entities / elements may be implemented in hardware in the same manner as described above with reference to blockchain nodes 104.

[0067] It will be understood that the above embodiments are described by way of example only. More generally, there is provided a method, an apparatus, or a program according to any of the following statements:

[0068] The present invention is generally a computer-implemented method for encrypting or decrypting data or portions thereof using blockchain content. The content can be customized, i.e., with specific parameters or references. The content is used as input to the encryption or decryption process.

[0069] Enumerated clauses It will be understood that the above embodiments are described for illustrative purposes only. More generally, a method, apparatus, system, or program may be provided according to any one or more of the following clauses or as described / illustrated herein: A zone may also be referred to as a "data structure" or "environment". A zone is similar to a room within a larger structure. An actor may be referred to as a user or an operator. A domain may be referred to as a computing system and is composed of one or more physical, virtual software, and / or firmware-based resources, such as a network architecture, virtual machines, code segments, etc. In some examples, a room may be provided using an execution thread, process, or instance running on a processor.

[0070] In one or more embodiments, actors may be subscribers to IPv6 multicast groups, and actors can "enter" or "exit" a zone by subscribing / unsubscribing to IPv6 multicast groups.

[0071] These provisions generally relate to broadcasting the presence of, or proximity to, a first actor (O1) in a zone (Z) of a domain (D) that includes multiple zones (Z). The terms "presence" and "proximity" may be used to describe an actor's relationship to a domain and / or location / location relative to the domain. In physical form, an actor may be "present" in the domain or in the vicinity of the domain or in a part of it. However, a virtual entity may not be physically present or near in the domain or in a part of it, but may be near, "present" or have a "presence" by virtue of being related to the domain or a part of it. In other words, a virtual entity may be present in the domain by being associated and operational or currently active, e.g., in service. The terms "presence" and "proximity" may be applied to virtual entities because they may be relevant or visible, i.e., relevant, to other actors when they are in the same domain / zone.

[0072] The teachings herein may be applied to real-world scenarios or situations, or representations thereof, where a first actor (user) may signal its presence or relevance to another (i.e., at least one other) actor, e.g., operating or currently active within the service of a zone. Additionally or alternatively, "relevance" may include interpretations of "relevant," "desiring to operate or be active within," and / or "need to interact." The at least one other actor may determine the presence, proximity, or status of the first actor by being in or near the same zone. The at least one other actor may need to be present or relevant to determine the proximity or status of the first actor. The at least one other actor may be limited to determining the absence of another actor.

[0073] In the example clause, the first actor (O 1 ) may be Alice, and / or at least one other actor may be Bob, or an actor authorized to act on behalf of Alice / Bob.

[0074] Clause 1: In one aspect, a first actor (O) in a zone (Z) of a domain (D) including multiple zones (Z) 1 A computer-implemented method includes broadcasting, indicating, or otherwise providing the presence of a first actor (O 1 ) in the domain. 2 ), the proximity of the first actor with respect to the zone (Z) to at least one other actor (O 2 A first actor may transmit, instruct, or otherwise provide data to at least one other actor by sending at least one transmission that includes the data or a means for computing / obtaining the data.

[0075] The data may include a secret. The secret may be or include an identifier. The secret / identifier may be a key or include a means to generate a key. The key may be a cryptographic key. The secret / key / identifier may be derived from or obtained using a master secret / key / identifier.

[0076] According to an additional or alternative form of expression, a computer-implemented method is provided, the method comprising: 1 ) to at least one other actor, and at least one other actor (O 2) to determine the proximity of the first actor to a zone (Z) in the domain. Determining the proximity of the first actor to a zone can include determining the presence of the first actor in the zone and / or absence outside the zone. "Presence" can include physical presence or virtual presence depending on the application. Virtual presence can include, for example, the active status, membership, or association of the first actor with respect to the zone.

[0077] A domain may be a network and may be used to define an environment or domain, such as a warehouse, or may be defined by an environment or domain. A zone may be an asset within a domain and may be used to define a sub-environment or sub-domain, or may be defined by an environment or domain. A zone may be a component of a domain.

[0078] The first actor is responsible for determining whether at least one other actor (O 2 ) to make its presence known. The transmission may be at least one of a communication, a message, or a packet. The at least one other actor may be limited to determining from the data in the transmission that another actor is not present.

[0079] Thus, in some embodiments, the present disclosure allows actors to monitor a domain or portions thereof and / or allows multiple actors to determine the presence of other actors and engage and interact with them within the current zone they occupy, i.e., reside in. The domain and its portions may represent real-world and / or digital assets. The assets may have functions and / or variables. The embodiments provide an enhanced cryptographically secure solution for handling sensitive or confidential data within the domain, providing a platform and / or underlying mechanisms that can be advantageously utilized by a variety of technical implementations.

[0080] Clause 2: The first actor (O 1 ) may further send at least one further transmission, which may include at least one other actor (O 2 ) determines the proximity of a first actor with respect to a zone (Z) within a domain (X).

[0081] For example, the data that allows determining the presence of the first actor may be zone, e.g., location, dependent. Thus, only other actors that have access to the same data can verify the presence of the first actor. For example, the data may include a room identifier in a hotel. The data may further include, for example, data indicating which floor or wing the first actor is on. In this way, only other actors on the same floor, wing, or room can determine the presence (e.g., being in the same room) and / or proximity (e.g., being in the same wing or floor of the hotel) of the first actor.

[0082] Clause 3: A first actor may send at least one transmission and / or at least one further transmission to all actors present in a domain (D).

[0083] By transmitting information to all other actors, and all other actors performing the same action, a first actor can determine the presence and / or proximity of all other actors in a zone and / or domain. Actions performed by an actor can therefore take into account the actions of other actors on the same zone or assets therein. Actors can therefore synchronize actions to prevent overlapping / conflicting results in cases where actions of multiple users may occur at different times, supporting eventual consistency of a domain and the zones therein.

[0084] Clause 4: A domain (D) further includes at least one of a subdomain (sD) and a subzone (sZ).

[0085] Clause 5: At least one of the zone (Z), domain (D), subdomain (sD), and subzone (sZ) may include an identifier.

[0086] Clause 6: The identifier may be unique for each of the zone (Z), domain (D), subdomain (sD), and subzone (sZ), derived from a master key, included in at least one transmission and / or at least one additional transmission, updated at predetermined intervals, and generated, modified, replaced, or updated by at least one of the zone (Z), domain (D), subdomain (sD), and subzone (sZ). In some exemplary embodiments, this may be performed at predetermined intervals (e.g., every hour), or when a specified condition is met (e.g., when five or more actors are present in the zone), or upon a trigger event (e.g., when an administrator or other controller initiates an update). The identifier may be generated by at least one of the zone (Z), domain (D), subdomain (sD), and subzone (sZ).

[0087] Identifiers function to allow actors to determine their presence. Additionally or alternatively, identifiers provide a unique, updateable means by which actors within a domain / zone can transmit dynamic changes in their presence. For example, each actor operating within a domain / zone and / or moving between zones of the domain can transmit data indicating their presence each time they change zones within the domain and / or can transmit data periodically. With all actors transmitting data, the presence of all actors can be dynamically determined and / or monitored. In other words, the movements and / or behavior of actors can be tracked and recorded on an ongoing basis.

[0088] Clause 7: The at least one transmission and / or the at least one further transmission may include a commitment to identify the presence and / or absence of the first actor, and / or a commitment to perform a function within the zone, and / or a commitment to modify properties (attributes) of the zone.

[0089] The data in a transmission may serve the function of conveying a message in a secure manner, such as instructions for a planned action. A commitment may be used to establish a shared secret between two or more actors who are aware of each other's existence.

[0090] Clause 8: At least one transmission and / or at least one further transmission may contain or include an indicator that informs the recipient of at least one of the first actor's access level, presence, and / or purpose with respect to at least one of a zone (Z), a domain (D), a subdomain (sD), and a subzone (sZ).

[0091] Additionally or alternatively, data in a transmission sent by a first actor may serve to determine a hierarchy or order of actions to be performed within a zone of a domain.

[0092] Clause 9: At least one transmission and / or the further transmission is 1 |p) and / or h(R 1 |q), where h represents a hash function applied to at least one transmission and / or at least one further transmission. 1 is an identifier of the zone (Z), domain (D), subdomain (sD), or subzone (sZ) in which the first actor resides, and |p and |q are indicators that, concatenated with the zone identifier, inform the recipient of at least one of the access level, presence, and / or purpose of the first actor with respect to the zone.

[0093] Clause 10: A zone (Z), domain (D), subdomain (sD), or subzone (sZ) is at least one of a physical entity represented by spatial or geospatial data, a virtual zone in a virtual domain, and an entry in a database or data table.

[0094] Clause 11: A zone (Z), domain (D), subdomain (sD), or subzone (sZ) has functions and / or variables and / or is controlled by a program that represents the zone.

[0095] Clause 12: The domain (D) may be at least one of a distributed data structure and / or one constructed on a distributed ledger.

[0096] Clause 13: The method may further include at least one of the steps of engaging and / or communicating with another actor, securing the zone, and modifying a variable of the zone.

[0097] Once the presence of another actor in a zone is identified, the first actor can contact the other actor to establish secure communications with each other and / or with the zone. Additionally or alternatively, actors present in a zone can contact each other to modify the status or variables of the zone.

[0098] Clause 14: The operations and / or variables of each zone and / or domain may be recorded, at least in part, in at least one of a database and a blockchain ledger.

[0099] Clause 15: The method includes: 2 ), which enables the first actor to determine the presence and / or absence of at least another actor.

[0100] Clause 16: The method further includes broadcasting a commitment to all actors in the domain (D), the commitment being transmitted to the first actor (O n ) and at least another actor (O 2 Upon determining the existence of a commitment, the method may include providing proof of the commitment and establishing secure communication with at least another actor.

[0101] Clause 17: In another aspect, a computer-implemented method includes steps of controlling and / or monitoring a system representing a domain (D) including a plurality of zones (Z), detecting a first actor (O) in a zone (Z) of the domain (D) including the plurality of zones (Z), n ), and receiving data from the domain and / or zone that enables the system to determine the presence and / or absence of another actor with respect to the zone (Z).

[0102] Clause 18: At least one of the multiple zones may be implemented using tokenized resources.

[0103] In another aspect, there is a computing device comprising a memory comprising one or more memory units and a processing device comprising one or more processing units, the memory storing code arranged to execute on the processing device, the code being configured, when executed on the processing device, to perform a method as recited in the claims.

[0104] In another aspect, there is a computer program embodied in a computer readable storage device and configured, when executed on one or more processors, to perform the methods set forth in the claims.

[0105] Blockchain-related background With particular reference to Figures 1 to 4, examples of background information related to blockchain implementation techniques are provided below that can provide an implementation environment for certain embodiments of the present disclosure. The term "blockchain" refers to a form of distributed data structure in which a duplicate copy of the blockchain is maintained at each of multiple nodes in a distributed peer-to-peer (P2P) network (hereinafter referred to as a "blockchain network") and made publicly available. The blockchain is composed of a chain of blocks of data, with each block being composed of one or more transactions. Each transaction, other than a so-called "coinbase transaction," points to a previous transaction in a sequence spanning one or more blocks that backs up to one or more coinbase transactions. Coinbase transactions are described in more detail below. Transactions submitted to the blockchain network are included in new blocks. New blocks are created by a process often called "mining." In this process, each of multiple nodes competes to perform a "proof of work," i.e., to solve a cryptographic puzzle based on a representation of a predefined set of ordered and validated pending transactions waiting to be included in a new block of the blockchain. Note that the blockchain may be pruned at some nodes and publication of blocks can be achieved by publishing only the block headers.

[0106] A transaction in a blockchain can be used for one or more of the following purposes, such as to convey digital assets (i.e., a number of digital tokens), to order a set of entries in a virtualized ledger or registry, to receive and process timestamp entries, and / or to chronologically order index pointers. A blockchain can also be used to layer additional functionality on top of the blockchain. For example, the blockchain protocol allows additional user data or indexes to be stored on the data within a transaction. Since there is no pre-specified limit on the maximum amount of data that can be stored within a single transaction, increasingly complex data can be incorporated. For example, this can be used to store electronic documents or audio and video data on the blockchain.

[0107] Nodes in a blockchain network (often called "miners") perform a distributed transaction registration and validation process, which is described in more detail below. In summary, during this process, nodes validate transactions and insert them into a block template in an attempt to identify a valid proof-of-work solution. Once a valid solution is found, a new block is propagated to other nodes in the network, allowing each node to record the new block in the blockchain. To record a transaction in the blockchain, a user (e.g., a blockchain client application) submits the transaction to one of the nodes in the network, which propagates it. Nodes that receive the transaction may compete to find a proof-of-work solution that will incorporate the validated transaction into a new block. Each node is configured to apply the same node protocol, which includes one or more conditions for a transaction to be valid. Invalid transactions are not propagated or incorporated into blocks. Once a transaction is validated and accepted into the blockchain, the transaction (including the user data) remains registered and indexed with each node in the blockchain network as an immutable public record.

[0108] The node that solves the proof-of-work puzzle and creates the latest block is rewarded with a new transaction, called a "coinbase transaction," which typically distributes a fixed amount of digital assets, or number of tokens. The detection and rejection of invalid transactions is performed by the actions of competing nodes, who act as agents of the network and are incentivized to report and block misconduct. Widely published information allows users to continuously audit node performance. By publishing only block headers, participants can ensure the ongoing integrity of the blockchain.

[0109] In the “output-based” model (sometimes called the UTXO-based model), the data structure of a particular transaction consists of one or more inputs and one or more outputs. A usable output consists of an element that specifies the amount of digital assets obtained from a series of transactions. A usable output is sometimes called a UTXO (or “unspent transaction output”). An output may also include a locking script that specifies the future redemption conditions of the output. A locking script is a predicate that defines the conditions required to validate and transfer a digital token or asset. Each input of a transaction (other than a coinbase transaction) includes a pointer (i.e., a reference) to such an output of a preceding transaction and may further include an unlocking script to unlock the locking script of the pointed output. Now consider a pair of transactions, which we call the first transaction and the second transaction (or “target” transaction). The first transaction includes at least one output that includes a locking script that specifies the amount of digital assets and defines one or more conditions to unlock the output. The second target transaction consists of at least one input that includes a pointer to an output of the first transaction and an unlocking script to unlock the output of the first transaction.

[0110] In such a model, when a second target transaction is submitted to the blockchain network to be propagated and recorded in the blockchain, one validity criterion applied by each node is that the unlocking script meets all of one or more conditions defined in the locking script of the first transaction; another is that the output of the first transaction has not yet been redeemed by another previous valid transaction. A node that determines that the target transaction is invalid based on any of these conditions will not propagate it (potentially registering it as an invalid transaction rather than as a valid transaction) and will not include it in any new block recorded in the blockchain.

[0111] Another type of transaction model is the account-based model, where each transaction defines the amount to transfer by referring to the absolute balance of the account, rather than by referring to the UTXO of the previous transaction in the sequence of past transactions. The current state of every account is stored in a node separate from the blockchain and is constantly updated.

[0112] Exemplary System Overview FIG. 1 illustrates an exemplary system 100 for implementing a blockchain 150. The system 100 may comprise a packet-switched network 101, typically a wide-area internetwork such as the Internet. The packet-switched network 101 includes a number of blockchain nodes 104 that may be configured to form a peer-to-peer (P2P) network 106 within the packet-switched network 101. Although not illustrated, the blockchain nodes 104 may be configured as a near-complete graph. Thus, each blockchain node 104 is highly connected to the other blockchain nodes 104.

[0113] Each blockchain node 104 includes a peer computer device, with different ones of the nodes 104 belonging to different peers. Each blockchain node 104 includes a processing device including one or more processors, for example one or more central processing units (CPUs), accelerator processors, application specific processors and / or field programmable gate arrays (FPGAs), and other devices such as application specific integrated circuits (ASICs). Each node also includes a memory, i.e., a computer readable storage device in the form of a non-transitory computer readable medium. The memory may include one or more memory units employing one or more memory media, for example, a magnetic medium such as a hard disk, an electronic medium such as a solid state drive (SSD), a flash memory, or an EEPROM, and / or an optical medium such as an optical disk drive.

[0114] The blockchain 150 includes a chain of blocks 151 of data, with a respective copy of the blockchain 150 maintained at each of multiple blockchain nodes 104 in a distributed or blockchain network 106. As mentioned above, maintaining a copy of the blockchain 150 does not necessarily mean storing the blockchain 150 in its entirety. Instead, the blockchain 150 can be pruned so long as each blockchain node 150 stores the block header (described below) of each block 151. Each block 151 in the chain includes one or more transactions 152, where a transaction in this context refers to a type of data structure. The nature of the data structure depends on the type of transaction protocol used as part of the transaction model or scheme. A given blockchain uses one particular transaction protocol throughout. In one common type of transaction protocol, the data structure of each transaction 152 includes at least one input and at least one output. Each output specifies an amount that represents a quantity of a digital asset as property, an example of which is a user 103 to whom the output is cryptographically locked (requiring that user's signature or other solution to unlock it and thereby be redeemed or spent). Each input points to an output of a preceding transaction 152, thereby linking the transactions.

[0115] Each block 151 also contains a block pointer 155 that points to a previously created block 151 in the chain, defining an order for the blocks 151. Each transaction 152 (other than a coinbase transaction) contains a pointer to a previous transaction, defining an order for the sequence of transactions (Note: the sequence of transactions 152 is allowed to branch). The chain of blocks 151 dates back to a genesis block (Gb) 153, which was the first block in the chain. One or more original transactions 152 earlier in the chain 150 pointed to the genesis block 153 rather than to a preceding transaction.

[0116] Each of the blockchain nodes 104 is configured to forward transactions 152 to other blockchain nodes 104, thereby propagating the transactions 152 throughout the network 106. Each blockchain node 104 is configured to create blocks 151 and store a respective copy of the same blockchain 150 in its respective memory. Each blockchain node 104 also maintains an ordered set (or "pool") 154 of transactions 152 waiting to be incorporated into a block 151. The ordered pool 154 is often referred to as a "mempool." This term herein is not intended to be limited to any particular blockchain, protocol, or model. It refers to the ordered set of transactions that the node 104 has accepted as valid, for which the node 104 is obligated not to accept any other transactions that attempt to consume the same output.

[0117] For a given current transaction 152j, its (or each) input contains a pointer that references the output of a preceding transaction 152i in the sequence of transactions, specifying that this output should be redeemed or "consumed" in the current transaction 152j. In general, the preceding transaction can be any transaction in the ordered set 154 or any block 151. The preceding transaction 152i does not necessarily have to exist at the time the current transaction 152j is created or even sent to the network 106, but the preceding transaction 152i must exist and be validated for the current transaction to be valid. Thus, "preceding" in this specification refers to a preceding element in a logical sequence linked by a pointer, not necessarily at the time of creation or transmission in the temporal sequence, and therefore does not necessarily exclude transactions 152i, 152j from being created or transmitted out of sequence (see the discussion below regarding orphan transactions). The preceding transaction 152i can equally be referred to as a previous transaction or a preceding transaction.

[0118] The input of the current transaction 152j also includes an input authorization, e.g., the signature of the user 103a to which the output of the previous transaction 152i is locked. The output of the current transaction 152j can then be cryptographically locked to the new user or entity 103b. The current transaction 152j can thus transfer to the new user or entity 103b the amount defined in the input of the previous transaction 152i as defined in the output of the current transaction 152j. In some cases, the transaction 152 may have multiple outputs to divide the input amount among multiple users or entities (one of which may be the original user or entity 103a to provide change). In some cases, a transaction may also have multiple inputs to collect amounts from multiple outputs of one or more previous transactions and redistribute them to one or more outputs of the current transaction.

[0119] According to an output-based transaction protocol such as Bitcoin, when a party 103, such as an individual user or an organization, wants to enact a new transaction 152j (either manually or by an automated process adopted by the party), the enacting party sends the new transaction from its computer terminal 102 to a recipient. The enacting party or recipient will eventually send this transaction to one or more of the blockchain nodes 104 of the network 106 (currently typically a server or a data center, but in principle it could be other user terminals). It is also not excluded that the party 103 enacting the new transaction 152j sends this transaction directly to one or more of the blockchain nodes 104 and in some examples does not send it to a recipient. The blockchain nodes 104 that receive the transaction check whether the transaction is valid according to the blockchain node protocol applied at each of them. The blockchain node protocol typically requires that the blockchain nodes 104 check that the cryptographic signature in the new transaction 152j matches an expected signature, which depends on the previous transaction 152i in the ordered sequence of transactions 152. In such output-based transaction protocols, this may involve checking that a cryptographic signature or other authorization of party 103 included in the input of the new transaction 152j matches a condition defined in the output of the previous transaction 152i that the new transaction assigns, which typically involves at least checking that the cryptographic signature or other authorization in the input of the new transaction 152j unlocks the output of the previous transaction 152i to which the input of the new transaction is linked. This condition may be defined at least in part by a script included in the output of the previous transaction 152i. Alternatively, it may simply be fixed by the blockchain node protocol alone, or result from a combination of these.In any case, if the new transaction 152j is valid, the blockchain node 104 forwards it to one or more other blockchain nodes 104 in the blockchain network 106. These other blockchain nodes 104, following the same blockchain node protocol and applying the same tests, forward the new transaction 152j to one or more further nodes 104, and so on. In this manner, the new transaction is propagated throughout the network of blockchain nodes 104.

[0120] In the output-based model, the definition of whether a given output (e.g., UTXO) has been allocated (e.g., spent) is whether it has still been validly redeemed by the input of another, forward transaction 152j according to the blockchain node protocol. Another condition for a transaction to be valid is that the output of the preceding transaction 152i that it attempts to redeem has not yet been redeemed by another transaction. Again, if it is not valid, the transaction 152j is not propagated (unless it is flagged as invalid and propagated due to a warning) or recorded in the blockchain 150. This protects against double spending, where a transaction executor tries to allocate the output of the same transaction multiple times. On the other hand, the account-based model prevents double spending by maintaining an account balance. Again, since there is a defined order of transactions, the account balance has a single defined state at any point in time.

[0121] In addition to validating transactions, blockchain nodes 104 compete to be the first to create a block of transactions in a process commonly referred to as mining, supported by "proof of work." At the blockchain nodes 104, new transactions are added to an ordered pool 154 of valid transactions that have not yet appeared in a block 151 recorded on the blockchain 150. The blockchain nodes then compete to assemble a new valid block 151 of transactions 152 from an ordered set of transactions 154 by attempting to solve a cryptographic puzzle. Typically, this involves searching for a "nonce" value such that when the nonce is concatenated with a representation of the ordered pool of pending transactions 154 and hashed, the output of the hash satisfies a predefined condition. For example, the predefined condition could be that the output of the hash has a certain predefined number of leading zeros. This is just one particular type of proof of work puzzle, others are not excluded. A property of a hash function is that it has an unpredictable output for an input. Therefore, this search can only be performed by brute force, thus consuming a significant amount of processing resources at each blockchain node 104 attempting to solve the puzzle.

[0122] The first blockchain node 104 that solves the puzzle publishes this to the network 106, providing the solution as a proof that other blockchain nodes 104 in the network can easily check (given the hash solution, it is easy to check that it matches the hash output). The first blockchain node 104 propagates the block to a threshold consensus of other nodes that accept the block, thus enforcing the protocol rules. The ordered set of transactions 154 then becomes recorded as a new block 151 in the blockchain 150 by each of the blockchain nodes 104. A block pointer 155 is also assigned to the new block 151n that points to a previously created block 151n-1 in the chain. The significant amount of effort, e.g., in the form of a hash, required to create the proof-of-work solution signals the first node 104's willingness to follow the rules of the blockchain protocol. Such rules include not accepting a transaction as valid if it assigns the same output as a previously validated transaction, otherwise known as double spending. Once created, blocks 151 cannot be modified because they are known and maintained by each of the blockchain nodes 104 in the blockchain network 106. Block pointers 155 also impose an order on blocks 151. This therefore provides an immutable public ledger of transactions, as transactions 152 are recorded in ordered blocks at each blockchain node 104 in the network 106.

[0123] Note that different blockchain nodes 104 competing to solve the puzzle at any given time may do so based on different snapshots of the pool of transactions 154 that are not yet published at any given time, depending on when they started looking for a solution or the order in which the transactions were received. The first to solve each puzzle defines which transactions 152 will be included in the next new block 151n and in what order, and the current pool of unpublished transactions 154 is updated. The blockchain nodes 104 then compete to create blocks from the newly defined ordered pool of unpublished transactions 154, and so on. There is also a protocol to resolve any "forks" that may occur, which is when two blockchain nodes 104 solve the puzzle within such a short time of each other that opposing views of the blockchain are propagated between the nodes 104. In essence, whichever branch of the fork grows the longest becomes the definitive blockchain 150. Note that this should not affect users or agents of the network when the same transaction appears in both forks.

[0124] According to the Bitcoin blockchain (and most other blockchains), a node that successfully constructs a new block 104 is granted the ability to allocate a new additional accepted amount of digital assets in a new special type of transaction that distributes an additional defined amount of digital assets (as opposed to an agent-to-agent or user-to-user transaction that transfers digital assets from one agent or user to another). This special type of transaction is usually referred to as a "coinbase transaction," but may also be called an "initiation transaction" or "generation transaction." It typically forms the first transaction of a new block 151n. The proof of work signals the intention of the node constructing the new block to follow protocol rules that allow this special transaction to be redeemed later. Blockchain protocol rules may require a redemption period, e.g., 100 blocks, before this special transaction can be redeemed. Often, a regular (non-generating) transaction 152 also specifies an additional transaction fee in one of its outputs to further reward the blockchain node 104 that created the block 151n in which the transaction was published. This fee is commonly referred to as a "transaction fee" and is explained below.

[0125] Due to the resources involved in validating and publishing transactions, typically at least each of the blockchain nodes 104 takes the form of a server including one or more physical server units, or even an entire data center. However, in principle, any given blockchain node 104 can also take the form of a user terminal or a group of networked user terminals.

[0126] The memory of each blockchain node 104 stores software configured to execute on the processing unit of the blockchain node 104 to perform its respective one or more roles and process transactions 152 in accordance with the blockchain node protocol. It will be understood that any activity attributed to a blockchain node 104 herein may be performed by software executing on the processing unit of the respective computing device. The node software may be implemented in one or more applications at the application layer, or at a lower layer, such as the operating system layer or protocol layer, or any combination thereof.

[0127] Also connected to the network 101 are computer devices 102 of each of a number of parties 103 who assume the role of consuming users. These users may interact with the blockchain network 106 but do not participate in validating transactions or constructing blocks. Some of these users or agents 103 may act as senders and receivers in transactions. Other users may interact with the blockchain 150 without necessarily acting as senders or receivers. For example, some parties may act as storage entities that store copies of the blockchain 150 (e.g., having obtained a copy of the blockchain from a blockchain node 104).

[0128] Some or all of the parties 103 may be connected as part of a different network, for example a network overlaid on the blockchain network 106. Users of the blockchain network (often referred to as "clients") may be said to be part of a system that includes the blockchain network 106, but these users are not blockchain nodes 104 because they do not perform the necessary role of a blockchain node. Instead, each party 103 may interact with the blockchain network 106 by connecting (i.e., communicating) with a blockchain node 106, thereby utilizing the blockchain 150. Two parties 103 and their respective devices 102 are shown for illustrative purposes: a first party 103a and its respective computer device 102a, and a second party 103b and its respective computer device 102b. It will be understood that many more such parties 103 and their respective computer devices 102 may exist and participate in the system 100, but for convenience they are not illustrated. Each party 103 may be an individual or an organization. Purely by way of example, the first party 103a will be referred to herein as Alice and the second party 103b will be referred to as Bob, although it will be understood that this is not intended to be limiting and that references herein to Alice or Bob may be replaced with "first party" and "second party," respectively.

[0129] The computer equipment 102 of each party 103 comprises a respective processing device including one or more processors, e.g., one or more CPUs, GPUs, other accelerator processors, application specific processors, and / or FPGAs. The computer equipment 102 of each party 103 further includes a memory, i.e., a computer readable storage device in the form of a non-transitory computer readable medium. This memory may include one or more memory units employing one or more memory media, e.g., a magnetic medium such as a hard disk, an electronic medium such as a SSD, a flash memory, or an EEPROM, and / or an optical medium such as an optical disk drive. The memory on the computer equipment 102 of each party 103 stores software including a respective instance of at least one client application 105 configured to execute on the processing device. It will be understood that any activity attributed to a given party 103 herein may be performed using software executed on the processing device of the respective computer equipment 102. The computer equipment 102 of each party 103 includes at least one user terminal, e.g., a desktop or laptop computer, a tablet, a smartphone, or a wearable device such as a smart watch. The computing equipment 102 of a given party 103 may also include one or more other network-connected resources, such as cloud computing resources accessed via a user terminal.

[0130] The client application 105 may be initially provided on the computing equipment 102 of any given party 103 on a suitable computer-readable storage medium, for example downloaded from a server, or may be provided on a removable storage device such as a removable SSD, a flash memory key, a removable EEPROM, a removable magnetic disk drive, a magnetic floppy disk or tape, an optical disk such as a CD or DVD ROM, or a removable optical drive, or the like.

[0131] The client application 105 has at least a "wallet" function. It has two main functionalities. One of these is to allow each party 103 to create, authorize (e.g., sign), and send transactions 152 to one or more Bitcoin nodes 104 for subsequent propagation throughout the network of blockchain nodes 104 and thereby inclusion in the blockchain 150. The other is to report to each party the amount of digital assets it currently owns. In an output-based system, this second function involves reconciling amounts belonging to the party of interest as determined in the outputs of various transactions 152 scattered throughout the blockchain 150.

[0132] NOTE: Although various client functions may be described as being integrated into a given client application 105, this is not necessarily limiting, and instead any client functionality described herein may instead be implemented as a set of two or more different applications, for example, interfaced via an API or plugged into one another. More generally, client functionality may also be implemented at the application layer, or at a lower layer such as an operating system, or any combination of these. While the following will describe client application 105, it will be understood that this is not limiting.

[0133] An instance of a client application or software 105 on each computing device 102 is operatively coupled to at least one of the blockchain nodes 104 of the network 106. This allows the wallet function of the client 105 to send transactions 152 to the network 106. The client 105 can also contact the blockchain nodes 104 to query the blockchain 150 for any transactions in which the respective party 103 is a recipient (or indeed to inspect the transactions of other parties in the blockchain 150, since in an embodiment the blockchain 150 is a public facility that provides trust to transactions in part through its public visibility). The wallet function on each computing device 102 is configured to formulate and send transactions 152 according to a transaction protocol. As noted above, each blockchain node 104 executes software configured to validate transactions 152 according to a blockchain node protocol and forward transactions 152 for propagation throughout the blockchain network 106. The transaction protocol and the node protocol correspond to each other, and a given transaction protocol goes with a given node protocol and together implement a given transaction model. The same transaction protocol is used for all transactions 152 in the blockchain 150. The same node protocol is used by all nodes 104 in the network 106.

[0134] When a given party 103, say Alice, wants to send a new transaction 152j to be included in the blockchain 150, Alice formulates the new transaction (using the wallet functionality of Alice's client application 105) according to the relevant transaction protocol. Alice then sends the transaction 152 from her client application 105 to one or more blockchain nodes 104 to which she is connected. For example, this could be the blockchain node 104 that is most connected to Alice's computer 102. When any given blockchain node 104 receives a new transaction 152j, it processes it according to the blockchain node protocol and its respective role. This involves first checking whether the newly received transaction 152j satisfies certain conditions to be "valid", examples of which will be explained in more detail shortly. In some transaction protocols, the conditions for validity checking may be configurable per transaction by a script included in the transaction 152. Alternatively, this condition could simply be a built-in feature of the node protocol or be defined by a combination of the script and the node protocol.

[0135] Provided that the newly received transaction 152j passes the test for being considered valid (i.e., it is "validated"), any blockchain node 104 that receives the transaction 152j adds the new validated transaction 152 to the ordered set of transactions 154 maintained at that blockchain node 104. Additionally, any blockchain node 104 that receives the transaction 152j forward propagates the validated transaction 152 to one or more other blockchain nodes 104 in the network 106. Because each blockchain node 104 applies the same protocol, then, assuming the transaction 152j is valid, this means that it will be propagated throughout the network 106 immediately.

[0136] After being admitted into the ordered pool of pending transactions 154 maintained by a given blockchain node 104, that blockchain node 104 starts a race to solve a proof-of-work puzzle with the latest version of each pool 154 that contains the new transaction 152. (Recall that other blockchain nodes 104 may be trying to solve the puzzle based on different pools of transactions l54, but whoever gets there first defines the set of transactions included in the latest block 151. Eventually, the blockchain node 104 will have solved the puzzle for the part of the ordered pool 154 that contains Alice's transaction 152j.) After the proof-of-work is done for the pool 154 that contains the new transaction 152j, it immutably becomes part of one of the blocks 151 in the blockchain 150. Each transaction 152 contains a pointer to the previous transaction, so the order of the transactions is also immutably recorded.

[0137] Different blockchain nodes 104 may initially receive different instances of a given transaction and therefore have conflicting views about which instance is "valid" before the instances are published in a new block 151, at which point all blockchain nodes 104 agree that the published instance is the only valid instance. If a blockchain node 104 accepts one instance as valid and then discovers that a second instance has been recorded in the blockchain 150, it must accept it and discard (i.e., treat as invalid) the instance it originally accepted (i.e., the one not published in block 151).

[0138] An alternative type of transaction protocol operated by some blockchain networks may be referred to as an "account-based" protocol, as part of the account-based transaction model. In the account-based case, each transaction does not define the amount transferred by referencing the UTXO of the preceding transaction in the sequence of past transactions, but rather by referencing the absolute account balance. The current state of every account is stored and constantly updated by the nodes of the network, separate from the blockchain. In such a system, transactions are ordered using the running transaction tally (also called the "position") of the account. This value is signed by the sender as part of the cryptographic signature and hashed as part of the transaction reference calculation. In addition, an optional data field may also be signed in the transaction. This data field may point to a previous transaction, for example if a previous transaction ID is included in the data field.

[0139] UTXO-based model FIG. 2 illustrates an example of a transaction protocol. This is an example of a UTXO-based protocol. A transaction 152 (abbreviated as "Tx") is a fundamental data structure of a blockchain 150 (each block 151 contains one or more transactions 152). The following is described with reference to an output-based or "UTXO"-based protocol. However, this is not limited to all possible embodiments. It should be noted that the exemplary UTXO-based protocol is described with reference to Bitcoin, but could equally be implemented on other exemplary blockchain networks.

[0140] In the UTXO-based model, each transaction ("Tx") 152 comprises a data structure that includes one or more inputs 202 and one or more outputs 203. Each output 203 may include an unspent transaction output (UTXO) that may be used as a source of input 202 for another new transaction (if the UTXO has not yet been redeemed). The UTXO includes a value that specifies an amount of a digital asset. This represents a set number of tokens on the distributed ledger. The UTXO may also include, among other information, the transaction ID of the transaction from which it originated. The transaction data structure may also include a header 201 that may include indicators of the sizes of the input fields 202 and the output fields 203. The header 201 may also include the ID of the transaction. In an embodiment, the transaction ID is a hash of the transaction data (excluding the transaction ID itself) and is stored in the header 201 of the raw transaction 152 submitted to the node 104.

[0141] For example, Alice 103a wishes to create a transaction 152j that transfers an amount of a digital asset of interest to Bob 103b. In FIG. 2, Alice’s new transaction 152j begins with “Tx 1" which takes the amount of digital assets locked in Alice in the output 203 of the previous transaction 152i in the sequence and transfers at least a portion of it to Bob. The previous transaction 152i is labeled "Tx 0 " Tx 0 and Tx 1 are just arbitrary labels. They do not necessarily correspond to Tx 0 is also the first transaction on blockchain 151. 1 It does not mean that Tx is the next transaction in the pool 154. 1 may also refer to any preceding (i.e., previous) transaction that still has unspent outputs 203 locked to Alice.

[0142] Preceding transaction Tx 0 Alice creates a new transaction Tx 1 By the time Tx is created, or at least by the time it is sent to the network 106, it may already have been validated and included in a block 151 of the blockchain 150. It may already be included in one of the blocks 151 at that point, or may still be waiting in the ordered set 154, in which case it will be included in the new block 151 shortly. Alternatively, Tx 0 and Tx 1 may be created together and sent together to the network 106, or Tx 0 Tx if the node protocol allows for buffering of "orphan" transactions 1It is even possible that a transaction may be sent after a previous transaction. The phrases "preceding" and "successor" as used herein in the context of a sequence of transactions refer to the order of the transactions in the sequence as defined by the transaction pointers specified in the transaction (which transaction points to which other transaction, etc.). They may equally be replaced with "predecessor" and "successor", or "predecessor" and "descendant", "parent" and "child", or the like. This does not necessarily imply the order in which they are created, sent to the network 106, or arrive at any given blockchain node 104. Nevertheless, a subsequent transaction (descendant transaction or "child") that points to a previous transaction (previous transaction or "parent") is not validated until and unless the parent transaction is validated. A child that arrives at a blockchain node 104 before its parent is considered an orphan. It may be discarded or buffered for a period of time to await the parent, depending on the node protocol and / or node behavior.

[0143] Preceding transaction Tx 0 One of the one or more outputs 203 of 0 Each UTXO includes a value that specifies the amount of the digital asset represented by the UTXO, and a locking script that defines the conditions that must be met by the unlocking script in the input 202 of a subsequent transaction for the subsequent transaction to be validated and thus the UTXO to be successfully redeemed. Typically, the locking script locks the amount to a particular party (the beneficiary of the transaction in which it is included). That is, the locking script typically defines unlocking conditions, including a condition that the unlocking script in the input of a subsequent transaction includes a cryptographic signature of the party to whom the preceding transaction is locked.

[0144] A lock script (also called scriptPubKey) is a piece of code written in a domain-specific language recognized by the node protocol. A particular example of such a language is called "Script" (capital S) used in blockchain networks. A lock script specifies the information required to consume a transaction output 203, for example the requirements for Alice's signature. An unlock script appears within the output of a transaction. An unlock script (also called scriptSig) is a piece of code written in a domain-specific language that provides the information required to satisfy the criteria of the lock script. For example, this may include Bob's signature. An unlock script appears within the input 202 of a transaction.

[0145] Therefore, in the illustrated example, Tx 0 Output of 203 UTXO 0 is UTXO 0 In order for the UTXO to be redeemed (strictly speaking, 0 (For a subsequent transaction attempting to redeem the A Requires lock script [Checksig P A ] is equipped. A ] is the public key P from Alice’s public-private key pair. A Contains a representation (i.e., a hash) of Tx 1 The input 202 of the Tx 1 A pointer to a transaction Tx 0 The transaction ID, TxID0, is a hash of the entire Tx 1 The input 202 of the Tx 0 To distinguish it from any other possible output of Tx 0 UTXO within 0 Contains an index that identifies the Tx 1The input 202 is an unlock script containing Alice's cryptographic signature, created by Alice applying the private key from her key pair to a predefined portion of data (sometimes called a "message" in cryptography). <Sig P A The data (or "message") that needs to be signed by Alice to provide a valid signature may be defined by the lock script, or by the node protocol, or by a combination of these.

[0146] New transaction Tx 1 When the arrives at a blockchain node 104, the node applies the node protocol, which involves running the lock script and the unlock script together to check whether the unlock script satisfies the conditions defined in the lock script (where the conditions may include one or more criteria). In an embodiment, this involves concatenating the two scripts as follows: <Sig P A > <P A > || [Checksig P A ] Here, "||" represents concatenation, "<...>" means to put data on the stack, and "[...]" is a function that is constructed by lock script (a stack-based language in this example). Equivalently, scripts could be executed one after the other with a common stack, rather than concatenating the scripts. Either way, when executed together, the scripts will be executed in the order of Tx 0 Alice's public key P, as contained in the lock script in the output of A Using Tx 1 , the input of Tx contains Alice's signature, which signs the expected portion of the data. To perform this authentication, the expected portion of the data itself (the "message") must also be included. In an embodiment, the signed data is 1(Thus, there is no need to include a separate element specifying the signed portion of the data in plaintext, since that is already inherently present).

[0147] The details of authentication with public-private cryptography will be familiar to those skilled in the art. Essentially, if Alice signs a message using her private key, then given Alice's public key and the plaintext message, another entity, such as node 104, can authenticate that the message must have been signed by Alice. Signing typically involves hashing the message, signing the hash, and tagging this as the signature to the message, so that anyone holding the public key can authenticate the signature. Thus, it should be noted that references herein to signing a particular data portion or part of a transaction, etc., may, in embodiments, mean signing a hash of that data portion or part of a transaction.

[0148] Tx 1 The unlock script is Tx 0 If it satisfies one or more conditions specified in the lock script of (so, in the illustrated example, Alice's signature is Tx 1 If provided and authenticated by Tx 1 This means that the blockchain node 104 considers Tx 1 The blockchain node 104 also adds the transaction Tx 1 to one or more other blockchain nodes 104 in the network 106, whereby it is propagated throughout the network 106. 1 After being validated and entered into the blockchain, this is called Tx 0 from UTXO 0 Define Tx as consumed. 1Note that Tx can only be valid if it consumes an unconsumed transaction output 203. If it attempts to consume an output that has already been consumed by another transaction 152, Tx 1 is invalid even if all other conditions are met. Therefore, the blockchain node 104 0 It is also necessary to check whether the UTXO referenced in has already been spent (i.e., whether it already forms a valid input to another valid transaction). This is one of the reasons why it is important for the blockchain 150 to impose a defined order on transactions 152. Indeed, a given blockchain node 104 may maintain a separate database that marks which UTXOs 203 have been spent in which transactions 152, but what ultimately defines whether a UTXO is spent is whether it already forms a valid input to another valid transaction in the blockchain 150.

[0149] If the total amount specified in all outputs 203 of a given transaction 152 is greater than the total amount pointed to by all its inputs 202, this is another criterion for invalidity in most transaction models. Therefore, such a transaction is not propagated and is not included in block 151.

[0150] Note that in the UTXO-based transaction model, a given UTXO must be spent in its entirety. It is not possible to "leave" part of the amount defined in the UTXO as spent while another part is being spent. However, the amount from a UTXO can be split among multiple outputs of subsequent transactions. For example, Tx 0 In UTXO 0 The amount defined in is Tx 1 Therefore, if Alice sends UTXO to Bob, 0If Alice does not want to give the entire amount defined in Tx 1 The second output of the can be used to give yourself change or to pay another party.

[0151] In practice, Alice would normally also need to include a fee for any Bitcoin node 104 that successfully puts her transaction 104 into a block 151. If Alice does not include such a fee, Tx 0 will be rejected by the blockchain node 104 and therefore, although technically valid, will not be propagated and included in the blockchain 150 (the node protocol does not force blockchain nodes 104 to accept a transaction 152 if they do not want to do so). In some protocols, the transaction fee does not require its own separate output 203 (i.e., it does not require a separate UTXO). Instead, any difference between the total amount pointed to by the input 202 and the total amount specified in the output 203 of a given transaction 152 is automatically given to the blockchain node 104 that publishes the transaction. For example, the UTXO 0 A pointer to Tx 1 Only input to Tx 1 One output UTXO 1 Only UTXO 0 The amount of digital assets specified in is UTXO 1 If the difference is greater than the amount specified in UTXO 1 However, it is not necessarily excluded that, alternatively or in addition, the transaction fee may be explicitly specified in one of the UTXOs 203 of the transaction 152 itself.

[0152] Alice and Bob's digital assets consist of the UTXOs locked to them in any transaction 152 anywhere in the blockchain 150. Thus, typically, a given party's 103 assets are scattered throughout the UTXOs of various transactions 152 throughout the blockchain 150. There is no one number stored anywhere in the blockchain 150 that defines a given party's 103 total balance. It is the role of the wallet function in the client application 105 to collate together the values ​​of all the various UTXOs locked to each party that have not yet been spent in another onward transaction. This can be done by querying a copy of the blockchain 150 as stored in any of the Bitcoin nodes 104.

[0153] Note that script code is often expressed generally (i.e., without using a precise language). For example, an operation code (opcode) may be used to express a particular function. "OP_..." refers to a particular opcode in the Script language. As an example, OP_RETURN is an opcode in the Script language that, when preceded by OP_FALSE at the beginning of the lock script, creates a non-consumable output of the transaction that can store data within the transaction, thereby immutably recording the data in the blockchain 150. For example, the data may include a document that is desired to be stored in the blockchain.

[0154] Typically, the input for a transaction is a public key P AIn an embodiment, this is based on ECDSA using the elliptic curve secp256k1. The digital signature signs certain data. In some embodiments, for a given transaction, the signature signs some of the transaction inputs and some or all of the transaction outputs. The specific parts of the outputs it signs depend on the SIGHASH flag, which is typically a four-byte code included at the end of the signature that selects which outputs are signed (and thus fixed at the time of signing).

[0155] The lock script may be referred to as a "scriptPubKey", referring to the fact that it typically includes the public key of the party for whom the respective transaction is locked. The unlock script may be referred to as a "scriptSig", referring to the fact that it typically provides a corresponding signature. However, more generally, in all applications of the blockchain 150, it is not essential that the condition for a UTXO to be redeemed includes authenticating the signature. More generally, the scripting language may be used to define any condition or conditions. Thus, the more general terms "lock script" and "unlock script" may be preferred.

[0156] Side Channels As shown in FIG. 1, the client applications on each of Alice's and Bob's computing devices 102a, 120b, respectively, may include additional communication capabilities. This additional functionality allows Alice 103a to establish a separate side channel 107 with Bob 103b (at the instigation of either party or a third party). The side channel 107 allows for the exchange of data away from the blockchain network. Such communication is sometimes referred to as "off-chain" communication. For example, this may be used to exchange transactions 152 between Alice and Bob without the transaction (yet) being registered on the blockchain network 106 or progressing on the chain 150 until one of the parties chooses to broadcast it to the network 106. Sharing transactions in this manner is sometimes referred to as sharing a "transaction template." A transaction template may lack one or more inputs and / or outputs necessary to form a complete transaction. Alternatively, or in addition, the side channel 107 may be used to exchange any other transaction-related data, such as keys, negotiated amounts or terms, data content, etc.

[0157] The side channel 107 may be established over the same packet-switched network 101 as the blockchain network 106. Alternatively, or in addition, the side channel 301 may be established over a different network, such as a mobile cellular network, or a local area network, such as a local wireless network, or even over a direct wired or wireless link between Alice's device 102a and Bob's device 102b. In general, the side channel 107 referenced anywhere herein may include any one or more links over one or more network technologies or communication media for exchanging data "off-chain," i.e., separate from the blockchain network 106. When multiple links are used, the bundle or collection of off-chain links may be referred to as the side channel 107 as a whole. Thus, it should be noted that when Alice and Bob are said to exchange some information or data or the like over the side channel 107, this does not necessarily imply that all pieces of these data must be transmitted over the exact same link or the same type of network.

[0158] Client Software FIG. 3A illustrates an example implementation of a client application 105 for implementing an embodiment of the presently disclosed scheme. The client application 105 includes a transaction engine 401 and a user interface (UI) layer 402. The transaction engine 401 is configured to implement basic transaction-related functions of the client 105, such as creating transactions 152, receiving and / or sending transactions and other data via side channels 301, and / or sending transactions to one or more nodes 104 (propagating through the blockchain network 106). These functions are performed according to the schemes described above and in more detail below. According to the embodiments disclosed herein, the transaction engine 401 of each client 105 comprises functionality 403.

[0159] The UI layer 402 is configured to render a user interface via the user input / output (I / O) means of each user's computing device 102, including outputting information to each user 103 via the user output means of the device 102 and receiving input from each user 103 via the user input means of the device 102. For example, the user output means may include one or more display screens (touch screen or non-touch screen) for providing visual output, one or more speakers for providing audio output, and / or one or more tactile output devices for providing tactile output, etc. The user input means may include, for example, an input array of one or more touch screens (same or different as used for the output means), one or more cursor-based devices such as a mouse, trackpad, or trackball, one or more microphones and voice or speech recognition algorithms for receiving voice or voice input, one or more gesture-based input devices for receiving input in the form of manual or physical gestures, or one or more mechanical buttons, switches, joysticks, etc.

[0160] NOTE: Although various functions herein are described as being integrated into the same client application 105, this is not necessarily limiting and instead may be implemented in a suite of two or more different applications, e.g. one may be a plug-in to the other and interface via an API (Application Programming Interface). For example, the functionality of the transaction engine 401 may be implemented in a separate application from the UI layer 402, and the functionality of a particular module such as the transaction engine 401 may be split between multiple applications. It is also not excluded that some or all of the described functionality may be implemented, for example, in the operating system layer. Where reference is made anywhere in this specification to a single application 105 or a particular application 105, etc., it will be understood that this is merely an example and that, more generally, the described functionality may be implemented in any form of software.

[0161] 3B shows a mockup of an example user interface (UI) 500 that may be rendered by the UI layer 402 of the client application 105a on Alice's device 102a. It will be appreciated that a similar UI may be rendered by the client 105b on Bob's device 102b or by other parties' devices.

[0162] For purposes of illustration, Figure 3B shows the UI 500 from Alice's perspective. The UI 500 is composed of one or more UI elements 501, 502, 502 that are rendered as separate UI elements by a user output means.

[0163] For example, the UI elements may include one or more user-selectable elements 501, such as different on-screen buttons, or different options in a menu. User input means are arranged to allow a user 103 (in this case Alice 103a) to select or manipulate one of the options by clicking or touching the UI elements on the screen or by speaking the name of the desired option (Note: the term "manual" as used here is used only in contrast to automatic and is not necessarily limited to use of the hand).

[0164] Alternatively, or in addition, the UI elements may include one or more data entry fields 502 through which the user can interact, which are rendered via a user output means (e.g., on a screen) and data can be entered into the fields via a user input means (e.g., a keyboard or touch screen). Alternatively, data may be received verbally, for example based on speech recognition.

[0165] Alternatively, or in addition, the UI elements may include one or more information elements 503 that are output to output information to the user, which may be rendered on a screen or audio, for example.

[0166] It will be understood that the particular means of rendering the various UI elements, selecting options, and inputting data is not important. The functionality of these UI elements will be described in more detail below. Also, the UI 500 shown in FIG. 3 is only a stylized mockup and may in fact include one or more additional UI elements, which are not shown for the sake of simplicity.

[0167] Node Software FIG. 4 illustrates an example of node software 450 executed by each blockchain node 104 of the network 106 in an example UTXO-based or output-based model. Note that another entity may execute the node software 450 without being classified as a node 104 on the network 106, i.e., without performing the actions required for a node 104. The node software 450 includes, but is not limited to, a protocol engine 451, a script engine 452, a stack 453, an application-level decision engine 454, and a set of one or more blockchain-related function modules 455. Each node 104 may execute node software including, but not limited to, all three of the following: a consensus module 455C (e.g., proof of work), a propagation module 455P, and a storage module 455S (e.g., database). The protocol engine 401 is typically configured to recognize various fields of the transaction 152 and process them according to the node protocol. Another prior transaction 152i (Tx m-1 ) output (e.g. UTXO). j ) is received, the protocol engine 451 j The protocol engine 451 identifies the unlock script in the Tx j Based on the pointer in the input of Tx i Identify and obtain Tx i may have been published to the blockchain 150, in which case the protocol engine may derive Tx from a copy of the block 151 of the blockchain 150 stored in the node 104. i Alternatively, you can get Tx i It is possible that Tx has not yet been published to the blockchain 150. In that case, the protocol engine 451 may select Tx from the ordered set of unpublished transactions 154 maintained by the node 104. i In either case, the script engine 451 can obtain Tx iand passes it to the script engine 452.

[0168] Therefore, the script engine 452 has Tx i The lock script and the corresponding input Tx j For example, Figure 2 shows the unlock script from Tx 0 Transactions labeled X and Tx are shown, but the same applies to any transaction pair. Script engine 452 executes the two scripts together as described above. This includes putting data onto and retrieving data from stack 453 according to the stack-based scripting language being used (e.g., Script).

[0169] By executing the scripts together, script engine 452 determines whether the unlock script meets one or more criteria defined in the lock script (i.e., whether the lock script "unlocks" the output it is contained in). Script engine 452 returns the result of this determination to protocol engine 451. If script engine 452 determines that the unlock script meets one or more criteria specified in the corresponding lock script, it returns the result "true". Otherwise, it returns the result "false".

[0170] In the output-based model, a "true" result from the script engine 452 is one of the conditions for the validity of a transaction. Typically, one or more protocol-level conditions evaluated by the protocol engine 451 must also be satisfied. For example, Tx j The total amount of digital assets pointed to by the output of Tx will not exceed the total amount pointed to by its input. jThe protocol engine 451 evaluates the results from the script engine 452 and one or more protocol-level conditions, and only if all are true does it accept the transaction Tx j The protocol engine 451 outputs an indication of whether the transaction is valid to the application-level decision engine 454. j Only on condition that Tx is actually validated, the decision engine 454 controls both the consensus module 455C and the propagation module 455P to j , for incorporation into a block 151. This includes having the consensus module 455C select the nodes' respective ordered transaction sets 154 to be tagged with Tx j and a propagation module 455P transmits the Tx j Optionally, in embodiments, the application-level decision engine 454 can apply one or more additional conditions before triggering either or both of these functions. For example, the decision engine can choose to publish a transaction only on the condition that the transaction is valid and that sufficient transaction fees remain.

[0171] Also, the terms "true" and "false" here are not necessarily limited to returning a result represented in the form of a single binary digit (bit), although that is certainly one possible implementation. More generally, "true" refers to any state that indicates success or a positive outcome, and "false" refers to any state that indicates failure or a non-positive outcome. For example, in an account-based model, a "true" outcome might be indicated by a combination of an implicit protocol-level validation of a signature and an additional positive output of a smart contract (if both individual outcomes are true, then the overall outcome is considered to indicate true). [Explanation of symbols]

[0172] 100 Systems 101 Packet Switching Network 102 Computer terminals 103 User, Parties 104 Blockchain nodes 105 Client Applications 107 Side Channel 150 Blockchain 151 Blocks of Data 151n Block 151n-1 Block 152 Transactions 152i Transactions 152j Transaction 153 Genesis Block (Gb) 155 Block Pointer 201 Header 202 Input 203 Output

Claims

1. 1. A computer-implemented method, comprising: The first actor (O) in a zone (Z) of a domain (D) with multiple zones (Z) 1 ), The first actor (O 1 ) is associated with at least one other actor (O 2 ) to transmit at least one transmission including data enabling the at least one other actor (O) in the domain to determine the proximity of the first actor with respect to the zone (Z). 2 ) how to send.

2. The first actor (O 1 ) further sends at least one further transmission, the at least one further transmission being directed to the at least one other actor (O 2 2. The method of claim 1, wherein said first actor is a member of said first and second domains, and wherein said first actor is a member of said second and third domains.

3. The method of claim 1 or 2, wherein the first actor sends the at least one transmission and / or at least one further transmission to all actors present in the domain (D).

4. The method of claim 1, wherein the domain (D) further comprises at least one of a subdomain (sD) and a subzone (sZ).

5. 5. The method of claim 1 or 4, wherein at least one of the zone (Z), the domain (D), the subdomain (sD), and the subzone (sZ) includes an identifier.

6. i) said identifier is unique for each of said zone (Z), said domain (D), said subdomain (sD), and said subzone (sZ); ii) the identifier comprises or is derived from a master key; iii) said identifier being included in said at least one transmission and / or at least one further transmission; iv) the identifier is changed, replaced or updated at predetermined intervals or upon satisfaction of specified conditions or execution of a trigger event; v) said identifier is generated by at least one of said zone (Z), said domain (D), said subdomain (sD), and said subzone (sZ); The method according to claim 5, further comprising applying at least one of the following:

7. The at least one transmission and / or the at least one further transmission further comprises: The method of claim 1 or 2, comprising a commitment to identify the presence and / or absence of the first actor and / or a commitment to perform a function within the zone and / or to modify properties of the zone.

8. the at least one transmission and / or the at least one further transmission includes an indicator; The method of any one of claims 1 to 7, wherein the indicator informs a recipient of at least one of the first actor's access level, presence, and / or purpose with respect to at least one of the zone (Z), the domain (D), subdomain (sD), and subzone (sZ).

9. The at least one transmission and / or the at least one further transmission comprises h(R 1 |p) and / or h(R 1 |q), h represents a hash function applied to said at least one transmission and / or said at least one further transmission; R 1 is an identifier of the zone (Z), the domain (D), the subdomain (sD), or the subzone (sZ) in which the first actor resides; The method of any one of claims 1 to 8, wherein |p and |q are indicators concatenated with a zone identifier to inform a recipient of at least one of the first actor's access level, presence, and / or purpose with respect to the zone.

10. The zone (Z), the domain (D), the subdomain (sD), or the subzone (sZ), The physical entities represented by the spatial or geospatial data; Can be represented as a virtual zone within a virtual domain, and Something that can be represented as an entry in a database or data table The method according to claims 1 to 9, wherein the method is at least one of the following:

11. The zone (Z), the domain (D), the subdomain (sD), or the subzone (sZ), With functions and / or variables; and / or The method according to any one of claims 1 to 10, controlled by a program representing said zones.

12. The domain (D) is (i) a distributed data structure; and / or (ii) Structured on a distributed ledger The method according to any one of claims 1 to 11, wherein the method is at least one of the following:

13. engaging and / or communicating to another actor; securing said zone; and Changing the variables of the zone. The method of any one of claims 1 to 12, further comprising at least one of:

14. The method according to claims 1 to 13, wherein the operations and / or variables of each zone and / or said domain are at least partially recorded in at least one of a database and a blockchain ledger.

15. The at least one other actor (O 2 ) receiving a response transmission from The method according to any one of claims 1 to 14, wherein said response transmission enables said first actor to determine said presence and / or absence of said at least one other actor.

16. broadcasting a commitment to all actors in the domain (D), the commitment being transmitted to the first actor (O n ) representing the identification of The at least other actor (O 2 providing a proof of said commitment when determining the existence of establishing a secure communication with said at least one other actor; The method of claims 1 to 15, further comprising:

17. controlling and / or monitoring a system representing a domain (D) having a number of zones (Z); A first actor (O) in a zone (Z) of a domain (D) having a plurality of zones (Z). n receiving a broadcast of a transmission indicating the presence of receiving data from said domain and / or said zone that enables said system to determine the presence and / or absence of another actor with respect to said zone (Z); 4. A computer-implemented method comprising:

18. 20. The computer-implemented method of claim 17, wherein at least one of the plurality of zones is implemented using at least one tokenized resource.

19. 1. A computer device comprising: a memory having one or more memory units; A processing device having one or more processing units, the memory storing code configured to be executed on the processing device, the code being configured, when executed on the processing device, to perform the method of any one of claims 1 to 18.

20. A computer program embodied on a computer readable storage, configured to perform the method according to any one of claims 1 to 18 when executed on one or more processors.

Images