Nodes for a network hosting a distributed ledger and corresponding methods and computer programs

Abstract

Examples relate to nodes for a network hosting a distributed ledger, and to corresponding methods and computer programs. A node for a network hosting a distributed ledger comprises at least one interface for communicating with other nodes of the network, and processor circuitry to execute a smart contract being hosted on the distributed ledger, the smart contract being configured to obtain a request of a user for joining a community associated with the smart contract, the request comprising at least a first proof of association with a cross-community identity and a second proof of non-membership in the community to be joined, verify the proofs included in the request, and initiate a join procedure to add the user to the community to be joined if the verification of the proofs is successful.

Description

[0001] Nodes for a Network Hosting a Distributed Ledger and Corresponding Methods and Computer Programs

[0002] Field

[0003] Examples relate to nodes for a network hosting a distributed ledger, and to corresponding methods and computer programs.

[0004] Background

[0005] The internet has enabled people around the globe to form online communities, where it is possible to preserve (at least partially) some anonymity. While this is a good thing and allows people to express themselves in ways that make them not worry about lifelong reputation effects, it also brings challenges. Bad actors, bots infiltrating and influencing networks, orchestrated fake news and intentionally malicious people can hide behind pseudonyms and disturb the correct functioning of communities.

[0006] The problem of bot networks infiltrating communities is well known. Systems to address this challenge, known as proof of uniqueness or proof of humanity have been developed (e.g. under the name of BrightID, Gitcoin Passport, Worldcoin, Privado ID with SSI + Passport certificates, etc.).

[0007] However, these systems may not shield communities from intentionally malicious actors spreading fake news, hate, showing aggressive behavior or sending spam to other members of the respective communities. Simple moderation does not address this challenge completely, as the malicious actors can continue their actions in other communities under a different pseudonym, or in communities using a different proof of uniqueness system.

[0008] At the same time, different communities apply different rules with respect to acceptable behavior. For example, in a football fan community, what is deemed acceptable may be different from what is deemed acceptable in an academic research circle. Thus, in analogy to the real world, an individual should still be allowed to express themself differently in different communities.

[0009] There may be a desire for providing an improved concept for shielding communities of malicious actors.Summary

[0010] This desire is addressed by the subject matter of the independent claims.

[0011] The proposed concept is based on the finding that many other systems do not provide a privacy-preserving reputation system that works across communities. In particular, if a user wants to join a community and needs to prove he or she already has a good standing in another community, the user often needs to reveal their identity in the other community, enabling the community to be joined to verify the claims of the user desiring to join the community. In the proposed concept, this is avoided by creating a smart contract-based system that lets communities verify a membership of a user in other communities without revealing their identity (e.g., pseudonym) in the respective community. In particular, proofs (e.g., zeroknowledge proofs and / or proofs of ownership of a private key) are used to demonstrate to the community to be joined that the user has a cross-community identity (tying together the various communities) and has not previously joined the community the user is trying to join now (to prevent a malicious actor from re-joining a community under a new pseudonym). Via the cross-community identity, the user can be asked to prove that he or she has, e.g., in each of the communities that are associated with the user’s account, a good standing. This way, community creators and moderators can impose rules on behavior for new members before joining and while participating in the community, while also considering behavior from other communities.

[0012] Some aspects of the present disclosure relate to a node for a network hosting a distributed ledger. The node comprises at least one interface for communicating with other nodes of the network, and processor circuitry to execute a smart contract being hosted on the distributed ledger. The smart contract is configured to obtain a request of a user for joining a community associated with the smart contract. The request comprises at least a first proof of association with a cross-community identity and a second proof of non-membership in the community to be joined. The smart contract is configured to verify the proofs included in the request. The smart contract is configured to initiate a join procedure to add the user to the community to be joined if the verification of the proofs is successful. By asking the user to provide a proof that he or she is not already a member of the community to be joined, malicious actors can be prevented from rejoining a community. By asking the user to provide a proof with respect to having a cross-community identity, the user can be requested to provide proof that he or she has a good standing in other communities using the cross-community identity-basedsystem. Together, the mechanisms can be used to prevent malicious actors from joining communities.

[0013] To further strengthen the verification process, e.g., in case the user already has an identity in another community using the cross-community identity-based system, the user can also be asked to provide proof that he or she has a good standing in the other community. In other words, the request may further comprise a third proof of the user fulfilling at least one reputation criterion in at least one further community. This way, communities can only allow users to join if they already have a (positive) reputation in at least one other community.

[0014] One mechanism for proving knowledge of a fact or ownership of something is based on zeroknowledge proof. In particular, a user providing a proof can input a (secret) value into an algorithm, which provides a result, such as a hash value or Merkle tree root hash (a root hash of a complete Merkle tree of data values). If the result is an expected result (e.g., a result that is stored in the smart contract), the user is deemed to be in possession of the secret value. For example, in the proposed concept, the secret value may be a set of pseudonyms or usernames of the user that are linked by the cross-community identity, with the smart contract storing a hash value that can only be obtained if all of the pseudonyms or usernames are used as input for a hashing function. To prove that the user is not previously a member of the community to be joined, he or she can generate, using a zero-knowledge proof, a set of hash values of the individual pseudonyms or usernames, except a username or pseudonym of the community to be joined. The zero-knowledge proof can then combine the set of hash values with another hash value that is used for cases where a cross-community identity is not a member in the respective community (or simply not provide a hash value of an identify of the community to be joined, depending on the algorithm). Accordingly, the second proof of nonmembership in the community to be joined may use a set of hash values being verifiable against a hashed state stored for the cross-community identity in the smart contract or in another smart contract. If the combined hashes correspond to the hashed state that is stored in the smart contract, the user has successfully proven non-membership in the community to be joined. In other words, the act of verifying the second proof may comprise verifying the respective set of hashed values against the hashed state stored for the cross-community identity. In particular, verifying the second proof of non-membership in the community to be joined may comprise verifying that the second proof uses correct hash values of any user account identifier being associated with the cross-community identity. Depending on implementation, the proof may one of a) use a hash value derived from a default value for the user account identifier for the community to be joined, b) use a default hash value for the user account identifier for the community to be joined, or c) exclude a hash value for the useraccount identifier for the community to be joined. This way, the smart contract can verify that the user has provided all of their user account identifiers, which do not include a user account identifier for the community to be joined.

[0015] Similarly, for the third proof of the user fulfilling at least one reputation criterion in at least one further community, the third proof may comprise the (hashed) username(s) or pseudonym(s) of the user in the further community(s), along with information on the reputation of the user in the respective community. Hashed versions of this or these username(s) or pseudonym(s) (user account identifier(s)) can again be combined to generate a combined hash value. If the combination of the hashes provided yields the hashed state, the user has successfully proven that he or she has the reputation claimed. Accordingly, the third proof of the user fulfilling at least one reputation criterion in at least one further community may use a set of hash values being verifiable against a hashed state stored for the cross-community identity in the smart contract or in another smart contract. The act of verifying the third proof may comprise verifying the respective set of hashed values against the hashed state stored for the cross-community identity.

[0016] In particular, verifying the third proof of the user fulfilling at least one reputation criterion in at least one further community may comprise verifying that the third proof uses hash values that indicate that, for each of the at least one further community, there exists a reputation score document provided by the respective further community that adheres to a reputation requirement of the community to be joined. The reputation score document may be associated with a user account identifier for the respective further community, and the user account identifier may be associated with the cross-community user identifier. Thus, the user cannot omit reputation score documents that would fail the reputation requirement, as the proof is only complete (i.e. , yields the hashed state) if the user has provided reputation score documents for each of the hashed user account identifier(s).

[0017] To protect the reputation score document(s) from tampering (e.g., inserting a different hashed user account identifier), the reputation score document(s) may be signed by the respective further community(s) providing the reputation score document(s). Thus, verifying the third proof may comprise verifying a signature of the reputation score document against a public key of the respective further community. The signature is a publicly inspectable piece of data that can be verified by anyone that has the public key of the signer. For this, the public key of the signer is typically made available somewhere in a way that cannot be tampered with e.g. in a smart contract. For example, the public key of the community may also be stored in a public mapping in a smart contract mapping community identifiers to public keys. This way,the public key can be retrieved from the smart contract during the verification of integrity of the reputation score document.

[0018] To ensure that the reputation score document(s) are provided with respect to the “right” reputation requirement (being provided by the community to be joined), also the reputation requirement included in the reputation score document(s) may be signed, by the community to be joined. Accordingly, verifying the third proof may comprise verifying a signature of the reputation requirement being used against a public key of the community to be joined.

[0019] As outlined above, different hash values (representing the different usernames or pseudonyms of the user) may be combined to yield the hashed state. Accordingly, the hashed state stored for the cross-community identity may be based on a combination of one or more hash values being based on any user account identifier being associated with the cross-community identity. This way, as hashes are generally not reversible, the user can provide the proofs without revealing their identity in the respective community(s).

[0020] Asymmetric encryption may be used to verify the first proof. In other words, verifying the first proof of association with the cross-community identity may comprise verifying a signature generated using a private key associated with the cross-community identity against a public key associated with the cross-community identity. Thus, the user may be required to include a signature with the request, which can be verified to prove that it is the user (being in possession of the private key) that is making the request to join the community.

[0021] One further part of the process of joining a community is the acquisition of a username or pseudonym (i.e. , of a user account identifier). To make joining the community and updating the hashed state a single process, proof of having acquired a user account identifier may already be included in the request. Accordingly, the request may further comprise a fourth proof of having acquired a user account identifier for the community to be joined, and a new hashed state that represents membership and non-membership of the cross-community identity in the communities after joining the community to be joined. For example, the smart contract may be configured to update the data structure (representing the membership and nonmembership of cross-community identities in the communities associated with the smart contract) of the smart contract or of a further smart contract to use the new hashed state for the cross-community identity.

[0022] In general, the data structure representing the membership and non-membership of crosscommunity identities in the communities associated with the smart contract may bemaintained (e.g., updated, provided) by the smart contract performing the join operation. Thus, the smart contract may be configured to maintain the data structure representing the membership and non-membership of cross-community identities in the communities associated with the smart contract. As outlined above, the data structure may comprise, for each cross-community identity, a hashed state representing the membership and non-membership of the cross-community identity in the communities associated with the smart contract.

[0023] At least some of the proofs outlined above are based on combining hash values (of user account identifiers) to yield a combined hash value that can be compared to the hashed state held by the data structure. To calculate the proofs, a so-called Merkle tree can be used. A Merkle tree is a data structure used in computer science and cryptography. It is a binary tree where each leaf node contains a hash of a data block, and each non-leaf node contains the hash of the concatenation of its child nodes' hashes. This hierarchical structure allows for efficient and secure verification of data integrity. In zero-knowledge proofs (such as at least some of the proofs used in the present disclosure), a Merkle tree can be used to prove membership of a data element in a larger set without revealing any additional information about the set, by combining the hashes of the leaves and intermediary nodes up to the root of the Merkle tree (representing the hashed state). In other words, the data structure may comprise at least one Merkle tree for calculating proofs to be verified against the hashed state of the respective cross-community identity.

[0024] When a new cross-community identity is registered, it is added to the data structure. As the new cross-community identity has not joined any of the communities, the data structure initially indicates that the cross-community identity is a non-member in any of the communities. Accordingly, the smart contract may be configured to register a new cross-community identity by adding the cross-community identity to the data structure, with the data structure initially indicating that the newly registered cross-community identity is non-member in any community associated with the smart contract. For example, a new Merkle tree may be added to the data structure for the cross-community identity, with the new Merkle tree resulting in the hashed state.

[0025] To avoid cases in which a user registers several cross-community identities in the system, a verification may be required that the user is a human and previously unregistered at the data structure (e.g., using an existing proof of uniqueness-system). Accordingly, the act of registering the new cross-community identifier may comprise verifying that a user registering the cross-community identity is a human and that the human is previously unregistered at the data structure.Some aspects of the present disclosure relate to a corresponding method for a node for a network hosting a distributed ledger. The method comprises obtaining, by a smart contract being executed by the node, a request of a user for joining a community associated with the smart contract. The request comprises at least a first proof of association with a cross-community identity and a second proof of non-membership in the community to be joined. The method comprises verifying, by the smart contract, the proofs included in the request. The method comprises initiating, by the smart contract, a join procedure to add the user to the community to be joined if the verification of the proofs is successful.

[0026] Another aspect of the present disclosure relates to a non-transitory, computer-readable medium comprising a program code that, when the program code is executed on a processor, a computer, or a programmable hardware component, causes the processor, computer, or programmable hardware component to perform the above method.

[0027] Another aspect of the present disclosure relates to a computer program having a program code for performing the above method, when the computer program is executed on a computer, a processor, or a programmable hardware component.

[0028] As outlined above, in some cases, the smart contract being used for joining a community may be separate from the smart contract maintaining the data structure. Thus, some aspects of the present disclosure relate to a node for a network hosting a distributed ledger, comprising at least one interface for communicating with other nodes of the network, and processor circuitry to execute a smart contract being hosted on the distributed ledger. In this case, the smart contract is configured to maintain a data structure representing the membership and non-membership of cross-community identities in communities associated with the smart contract. The data structure comprises, for each cross-community identity, a hashed state representing the membership and non-membership of the cross-community identity in the communities associated with the smart contract. The smart contract is configured to provide, upon request, the hashed value representing the membership and non-membership of a crosscommunity identity in a community of the communities associated with the smart contract. This way, each community may use their own smart contract for letting users join the community, with the maintenance of the hashed state being centralized in a separate smart contract.

[0029] This smart contract may provide the functionality related to the properties and maintenance of the data structure discussed in connection with the smart contract being used to enable auser to join a community. For example, the data structure may comprise at least one Merkle tree for calculating proofs to be verified against the hashed state of the respective crosscommunity identity. For example, the smart contract may be configured to register a new cross-community identity by adding the cross-community identity to the data structure, with the data structure initially indicating that the newly registered cross-community identity is nonmember in any community associated with the smart contract. For example, the act of registering the new cross-community identifier may comprise verifying that a user registering the cross-community identity is a human and that the human is previously unregistered at the data structure.

[0030] Some aspects of the present disclosure relate to a corresponding method for a node for a network hosting a distributed ledger, the method comprising maintaining, by a smart contract, a data structure representing the membership and non-membership of cross-community identities in communities associated with the smart contract, with the data structure comprising, for each cross-community identity, a hashed state representing the membership and nonmembership of the cross-community identity in the communities associated with the smart contract. The method comprises providing, by the smart contract and upon request, the hashed value representing the membership and non-membership of a cross-community identity in a community of the communities associated with the smart contract.

[0031] Another aspect of the present disclosure relates to a non-transitory, computer-readable medium comprising a program code that, when the program code is executed on a processor, a computer, or a programmable hardware component, causes the processor, computer, or programmable hardware component to perform the above method.

[0032] Another aspect of the present disclosure relates to a computer program having a program code for performing the above method, when the computer program is executed on a computer, a processor, or a programmable hardware component.

[0033] Brief description of the Figures

[0034] Some examples of apparatuses and / or methods will be described in the following by way of example only, and with reference to the accompanying figures, in which

[0035] Fig. 1a shows a schematic diagram of an example of a node for a network hosting a distributed ledger;Fig. 1b shows a flow chart of a first method for a node for a network hosting a distributed ledger according to a first variant;

[0036] Fig. 1c shows a flow chart of the first method for a node for a network hosting a distributed ledger according to a second variant;

[0037] Fig. 1d shows a flow chart of a second method for a node for a network hosting a distributed ledger according to the second variant;

[0038] Fig. 2 shows an example of a communities smart contract;

[0039] Fig. 3a illustrates an example of a determination of a hashed state;

[0040] Fig. 3b illustrates a hashed state of a user after registering a cross-community identity; and

[0041] Fig. 3c illustrates a hashed state of a user after joining a community.

[0042] Detailed Description

[0043] Some examples are now described in more detail with reference to the enclosed figures. However, other possible examples are not limited to the features of these embodiments described in detail. Other examples may include modifications of the features as well as equivalents and alternatives to the features. Furthermore, the terminology used herein to describe certain examples should not be restrictive of further possible examples.

[0044] Throughout the description of the figures same or similar reference numerals refer to same or similar elements and / or features, which may be identical or implemented in a modified form while providing the same or a similar function. The thickness of lines, layers and / or areas in the figures may also be exaggerated for clarification.

[0045] When two elements A and B are combined using an “or”, this is to be understood as disclosing all possible combinations, i.e. only A, only B as well as A and B, unless expressly defined otherwise in the individual case. As an alternative wording for the same combinations, "at least one of A and B" or "A and / or B" may be used. This applies equivalently to combinations of more than two elements.If a singular form, such as “a”, “an” and “the” is used and the use of only a single element is not defined as mandatory either explicitly or implicitly, further examples may also use several elements to implement the same function. If a function is described below as implemented using multiple elements, further examples may implement the same function using a single element or a single processing entity. It is further understood that the terms "include", "including", "comprise" and / or "comprising", when used, describe the presence of the specified features, integers, steps, operations, processes, elements, components and / or a group thereof, but do not exclude the presence or addition of one or more other features, integers, steps, operations, processes, elements, components and / or a group thereof.

[0046] Fig. 1a shows a schematic diagram of an example of a node 10 for a network hosting a distributed ledger 100. A distributed ledger is a type of database that is shared, replicated, and synchronized among the members of a decentralized network. Unlike a traditional centralized database managed by a single entity, a distributed ledger spreads data across multiple locations, each held by different participants (nodes) in the network. This decentralized approach enhances transparency, security, and resilience, as all participants can see and verify the entries. A well-known example of a distributed ledger technology is blockchain, which organizes data into blocks that are linked in chronological order, making it difficult to alter past records without altering subsequent blocks. Ethereum and Solana are two other well-known examples of distributed ledger technology.

[0047] Smart contracts are self-executing contracts (i.e., computer programs) with the terms of the agreement between the participants written into code. These contracts are stored on and executed by a distributed ledger, allowing them to run automatically once predefined conditions are met. This automation reduces the need for intermediaries, lowers transaction costs, and minimizes human error. Smart contracts are widely used in various sectors, including finance, supply chain, and real estate, fortasks such as automating payments, verifying ownership, and ensuring compliance with regulatory requirements.

[0048] Smart contracts are predominantly used on distributed ledger platforms to facilitate, verify, or enforce the negotiation and performance of a contract by executing machine-readable instructions stored in the smart contract. When the conditions encoded in a smart contract are satisfied, the contract automatically executes the agreed-upon actions. The data and state of smart contracts are stored on the distributed ledger, ensuring transparency and immutability. Each contract's execution and results are recorded across the network, making it tamperproof and easily auditable.It is noted that smart contracts are, in many cases, unable to proactively send information to other entities, such as a platform or a user. Therefore, if the smart contract provides some piece of information to another entity, this is being done using a polling mechanism, i.e. , the other entity is actively polling the smart contract for this piece of information.

[0049] Fig. 1a shows a schematic diagram of an example of a node 10 for a network hosting a distributed ledger 100, which is configured to execute a smart contract 105a (and / or a second smart contract 105b) hosted on the distributed ledger. For this purpose, the node 10 comprises interface circuitry 12 for communicating with other hosts of the network, and processor circuitry 14 to execute the smart contract 105a and / or the second smart contract 105b. For example, the processor circuitry 14 may be configured to provide the functionality of the node 10, e.g., in conjunction with the interface circuitry 12 (for communicating with other nodes of the network, with a platform, or with one or more users). The processor circuitry 14 is coupled with the interface circuitry 12. For example, the processor circuitry 14 may be configured to execute machine-readable instructions to provide its functionality, i.e., to execute the smart contract. In particular, the processor circuitry 14 may be configured to run a virtual machine to participate in the distributed ledger, and thus also to execute the smart contract. In distributed ledgers, such as block chain, it is a virtual machine that executes the smart contracts, though effectively processors are executing code that emulates the virtual machine. Thus, the processor circuitry 14 may be configured to execute a virtual machine that runs smart contract transactions compiled to virtual machine bytecode. In a network hosting a distributed ledger, each node of the distributed ledger may execute the smart contract as part of a consensus process.

[0050] In the proposed concept, two different variants are supported - in a first variant, shown in Fig.

[0051] 1b, a smart contract 105a being used for joining a community also maintains a data structure containing a hashed state of cross-community identities. In a second variant, shown in Figs.

[0052] 1c and 1d, the smart contract 105a being used for joining a community is separate from a smart contract 105b that maintains a data structure containing the hashed state of crosscommunity identities. Therefore, three flow charts are provided that illustrate one or more methods for a node for a network hosting a distributed ledger, with Fig. 1b showing a method according to the first variant, and Figs. 1c and 1d showing a first and a second method according to the second variant.

[0053] Figs. 1b and 1c show flow charts of a first method for a node for a network hosting a distributed ledger, according to the first variant (Fig. 1b) and according to the second variant (Fig.

[0054] 1c). The method of Figs. 1b and 1c comprises the obtaining 130, by a smart contract beingexecuted by the node, of a request of a user for joining a community associated with the smart contract. The request comprises at least a first proof of association with a cross-community identity and a second proof of non-membership in the community to be joined. The method comprises verifying 140, by the smart contract, the proofs included in the request. The method comprises initiating 150, by the smart contract, a join procedure to add the user to the community to be joined if the verification of the proofs is successful. Accordingly, the smart contract 105a is configured to obtain a request of a user for joining a community associated with the smart contract, the request comprising at least a first proof of association with a cross-community identity and a second proof of non-membership in the community to be joined, verify the proofs included in the request, and initiate a join procedure to add the user to the community to be joined if the verification of the proofs is successful.

[0055] A second method, shown in Fig. 1d, relates to the maintenance of a data structure by the second smart contract 105b. The method of Fig. 1 d, and optionally the method of Fig. 1b, comprises maintaining 110, by the second smart contract 105b, a data structure representing the membership and non-membership of cross-community identities in communities associated with the smart contract. The data structure comprises, for each cross-community identity, a hashed state representing the membership and non-membership of the cross-community identity in the communities associated with the smart contract. The method of Fig. 1d, and optionally the method of Fig. 1b, further comprises providing 115, upon request, by the second smart contract 105b, the hashed value representing the membership and non-member-ship of a cross-community identity in a community of the communities associated with the smart contract. Accordingly, the second smart contract is configured to maintain the data structure representing the membership and non-membership of cross-community identities in communities associated with the smart contract, and to provide, upon request, the hashed value representing the membership and non-membership of a cross-community identity in a community of the communities associated with the smart contract.

[0056] The functionality of the smart contract(s) 105a, 105b, will now be introduced in more detail in connection with a proposed Cross-Community Online Reputation Scoring System (CCORSS). In the following, some optional elements are discussed, which may be used by the Cross-Community Online Reputation Scoring System (CCORSS).

[0057] The CCORSS is, at least partially, based on a reputation held by a user in online communities being linked by the CCORRS. In general, a user’s reputation may have multiple facets, as a single score may be too limited. For example, a user’s reputation can be scored on different facets that are universally valid for many communities, such as one or more of politeness,helpfulness, interesting views, value-adding, humor, hate speech, spam content, rudeness, aggressiveness, or illegal content. Reputation scores may be defined per community, as people can behave differently in different communities.

[0058] Every community may score a user’s behavior in this community on some or all of these facets, e.g., on a level between 0 and 100. In the case of a Reddit-like user discussion forum, such scores could be derived from the smiley reactions that people click on a message (e.g., laughing influences humor score, value-adding if people upvote, etc.). Alternatively, scoring could be implemented using an artificial intelligence (Al), such as a (large) language model, that scores every post on each of these criteria, or through manual moderation from chosen moderators. At every point in time, a user may have reputation scores on the multiple facets, e.g., in every community the user is part of.

[0059] To prevent bad behavior, two more aspects may be taken into account. In particular, account creation may be limited. (1) Users may be allowed to create anonymous accounts for every community, limiting to a maximum of 1 account per user per community and in a way they cannot deny having created that single account. In addition, (2) a community or community manager may be allowed to specify minimal acceptable reputation scores on different facets of a user, as generated from its activity in this or other communities they care about, in order to be allowed certain actions. To give some examples for (2), a community C might only allow members to join or post that either do not participate in community A (no score exists) or that have a score where Hate Speech == 0. A community D might allow members to join if they have not been aggressive in any community the user is part of (A, B, E, F, ...) and allowed to post if they have been Helpful (>50) in community B or D. A community E might only allow funny people from any community (Humor > 80) to post but allow anyone to join.

[0060] To limit account creation, as a prerequisite, proof of uniqueness may be required. To address point (1), any chosen proof of uniqueness system that is accepted by all the communities that share the cross-community reputation system may be used. For a new user to join any community, he or she may be required to have a uniqueness proof in the chosen system of the community groups (e.g. BrightID). Accordingly, with respect to the method(s) of Fig. 1b and 1c, the act of registering 120 a new cross-community identity may comprise verifying that a user registering the cross-community identity is a human and that the human is previously unregistered at a data structure being maintained by the smart contract or another smart contract. How this is implemented depends on the chosen system. In general, a user receives an Identity ID and a digital proof (zk Proof or blockchain written attestation) that cannot be forged, about their unique identity and a matching pair of keys to operate on the identity. If auser would ever re-attempt to get a proof of uniqueness from the same system, the user would either be denied or get the same Identity ID which already has an existing state. If the chosen list of worldwide Identity IDs is iterable by anyone (can be found online, extracted from smart contract storage, ...), the user may add a chosen cryptographic salt to the Identity ID. This has a minor impact on proof generation later, but can improve protection against reverse engineering community membership attacks.

[0061] Furthermore, identity identifiers (Identity IDs), community identifiers (community IDs) and memberships for a user may be stored on-chain. It may be preferred for the Identity ID for a user not to be linkable between different communities except by the user him- or herself. For this, the Identity ID might not ever be stored linked to a membership on-chain in a clear or reversible engineerable way. For example, a public blockchain with smart contracts for the reputation system may be used. In the smart contract, the following information may be stored: The list of all known Identities and their “state” (defined below), and the list of all communities (community ID and a public key per community).

[0062] When a community wants to join the CCORSS, it may be required to comply with the rules and requirements of the system, before then applying to the Decentralized Autonomous Organization (DAO) overseeing the community list. A community that wants to join the system may be required to provide a global unique community identifier, that is not yet in use by any other community, e.g., keccak256(“Reddit-Fishing”) for a community on decentralized social network Reddit about fishing. A community that wants to join the system may be required to provide an endpoint (first endpoint) and description where users can request their reputation scores, signed by the community. A community that wants to join the system may be required to provide a detailed description of how reputation will be calculated for each community member, e.g., whether it is based on manual moderation, automatic moderation, etc. and how (if any) appeal can be made against certain moderation decisions. This description may be made available on an endpoint (second endpoint) as well. A community that wants to join the system may be required to pay a yearly community membership fee (bond) to the DAO as well as a deposit that can be slashed by the DAO, to ensure that the endpoints always remain active.

[0063] The DAO may decide via voting on community membership, suspend, abandon or slashing of the bonds. It may also assign unique integers to every community (community ID) based on the order in which they join the CCORRS. The first community may have id 0, then 1, then 2, etc. The CCORSS may have a communities smart contract that maps community ID to status (active, inactive, ...), a public key for signing proofs from the community, the twoendpoints above, a start date and a paid balance in tokens. Fig. 2 shows an example of a communities smart contract. For each community (communityA, communityB and communi-tyC in Fig. 2), the smart contract contains its state, the public key, (a reference to) the two endpoint, and a balance. The smart contract further comprises information on a number of communities represented (communityCount) and contact information for the administrator of the smart contract (adminAddress). The smart contract further has endpoints to apply for a community (applyForCommunityO), to approve a community (approveCommunityO) and to update a community (updateCommunity).

[0064] The proposed concept primarily relates to the onboarding of users to a community that is active in CCORSS, e.g., a community associated with at least one of the smart contracts being referred to in connection with Figs. 1a to 1d. For example, the system may store a Global Identity State Root tree (GIST tree) of all users active in the system. In connection with Figs. 1a to 1 d, this GIST tree is referred to as data structure representing the membership and non-membership of cross-community identities in the communities associated with the smart contract. As shown in Fig. 1b and 1c, the smart contract may be configured to maintain 110 a data structure representing the membership and non-membership of cross-community identities in the communities associated with the smart contract. This GIST tree may be the root hash of a Merkle Tree of all identities (cross-community identities) in the system, where every identity maps to a state hash. This state hash is the state of the user as defined below. Accordingly, the data structure may comprise, for each cross-community identity, a hashed state representing the membership and non-membership of the cross-community identity in the communities associated with the smart contract. In particular, the data structure may comprise at least one Merkle tree for calculating proofs to be verified against the hashed state of the respective cross-community identity. The GIST tree is stored in a smart contract, and the structure is updated when a user joins the CCORSS system, and the leaf values (which map to user state) are updated when a user changes state (i.e. join / leave a community), as the smart contract maintains 110 the data structure. For example, the smart contract may be configured to register a new cross-community identity by adding the cross-community identity to the data structure (e.g., the GIST tree). The data structure may initially indicate that the newly registered cross-community identity is a non-member in any community associated with the smart contract. The user state may be stored in a Sparse Merkle tree, because this allows both easy proof of non-membership as well as proof of membership.

[0065] For state, a data structure (Merkle Tree, Sparse Merkle Tree, Ordered list, ..) is defined that allows proving membership or non-membership of certain communities, while only storing a state hash of the entire membership of that user. A naive implementation would be to have adepth-1 Merkle Tree where the root hash is the hash of the usernames (members) or null values (non member) of all known communities. Proofs are easy, but not perfect for communities being added. Fig. 3a illustrates an example of a determination of a hashed state being used for membership or non-membership of certain communities. The user 310 has an identity identifier 320 that has, as its state, hashed state 330. This hashed state is calculated based on the hashes of the hashed usernames 340a, 340b, 340d for communities A, B and D. In Fig. 3a, the user is not a member of community C.

[0066] When a user wants to onboard their first community A that accepts users without existing reputation score, they may be required to prove that they do not have any existing reputation yet. For this, the user may first register as a user of the cross-community reputation system, which creates their initial state. The user may then generate a proof to present to the community A that the user has an account that satisfies the proof of uniqueness but is not member of any communities yet (given his state). Based on this, the user can initiate a join community transaction for community A by bringing their combined proof.

[0067] To perform a user’s initial CCORSS onboarding and joining the first community, the user may use the configured proof of humanity / proof of authority system for obtaining an Identity ID X and a corresponding private key. The user wants to join community A that has no reputation requirements. The user may thus request a username II from community A and get a signature. The user may generate a proof P1 (which may be introduced below) and prove that the user is not part of any communities yet because Identity ID X has no existing hashed state. The user may calculate their first hashed state H by setting membership of community A to username II. The user may call the onboarding method on the smart contract, which may validate P1 and see the empty state in the smart contract for Identity ID X, then set the first state to H.

[0068] The gas (transaction fees) can be paid either by the user, the community or a paymaster of the community in the case of account abstraction. A user state transaction may occur on-chain to reflect his updated Merkle Tree root. This is shown in Figs. 3b and 3c. Fig. 3b illustrates a hashed state of a user after registering a cross-community identity. In Fig. 3b, user 310 has an Identity ID 320 with a hashed state 330 that is based on no memberships, as the user is a non-member in every community. Fig. 3c illustrates a hashed state of a user after joining a community. In Fig. 3c, after joining community A, the hashed state 330 is based on the (hashed) username of the user in community A. In more general terms, the hashed state stored for the cross-community identity may be based on a combination of one or more hashvalues based on any user account identifier being associated with the cross-community identity.

[0069] Based on this state, the user should be able to generate the following proofs: That the user is a member of community A, i.e., has a username in community A, and that the user is not a member of any other community, i.e., there is no username in communities B-Z that is related to this user. It should also be impossible for this user to prove that he has no Community A username (because he has one) and to prove for any other user or a user that has reverse engineered the Identity ID but does not own the private keys that they are a member of Community A.

[0070] In the following, a short introduction is given on the above two types of proofs. However, the same techniques may also be used for other proofs being used in the context of the present disclosure. In the present disclosure, mainly, two types of proofs are used: A first type of proof is proof of private key ownership, typically because a corresponding public key is stored somewhere freely available to anyone (e.g., in a smart contract). If a user or community can sign a random message with the private key, the public key can be used to verify correctness. A second type of proofs are zero-knowledge proofs. Zero-knowledge proofs prove the execution result of a certain function or algorithm, without revealing the private input that led to this execution result. Simple example: Given a hash value C, the user knows a username II so that HASH(u)=C. The user can generate a proof that he or she knows II that satisfies this equation without revealing it, but such that a verifier can verify the correctness of this proof. More information on zero-knowledge proofs can be found on Wikipedia. For example, in the context of the present disclosure, the first proof may be a proof of private key ownership, and the second, an optional third and an optional fourth proof may be zero-knowledge proofs. Alternatively, all of the proofs may be implemented as zero-knowledge proofs. These proofs can be combined into aggregated sets of proofs that operate on the same (private or non private) data and prove more complex things.

[0071] An example is given for proof P1 of owning an identity identifier (e.g., the first proof of association with a cross-community identity). To provide a proof of owning an Identity ID to a challenger, the user may sign a random message, given by the challenger, with the private key of the user. The challenger can verify proof P1 by checking the signature with the public key of the user (e.g., stored in the smart contract). Accordingly, verifying the first proof of association with the cross-community identity may comprise verifying a signature generated using a private key associated with the cross-community identity against a public key associated with the cross-community identity.Another example is given for proof P2 of having a certain community membership state in CCORSS (e.g., the second proof of non-membership in the community to be joined). As shown in Fig. 3a to 3c, a CCORSS smart contract (e.g., one of the smart contracts 105a, 105b discussed in connection with Figs. 1a to 1d) stores a mapping of Identity ID to a hashed state (explained later) on a public blockchain. Given an Identity ID, anyone can obtain the hashed state of a user. The hashed state is calculated from the individual community states of an Identity ID. If a user with Identity ID X is part of Community A and has username II in this community, the hashed state of Community A is:

[0072] CommState A, X) = HASH A | X | [ / )

[0073] where | is a string concatenation and where HASH is any hash function e.g. SHA256. Here A is the community ID, which is a number going from 0 to the number of communities in the system. If a user with Identity IDX is not part of Community A, the hashed state of Community A may be an empty string. To calculate the overall hashed state for a user, the hash of the concatenation of all of the community hashed states may be combined.

[0074] Hashed State ( X )

[0075] = HASH(CommState A,X) | CommState B,X) | CommState(C , ) | CommState D,Xy)

[0076] If a user is part of only community A, the hashed State is the hash of the CommState(A,X), which itself is a hash (i.e., a hash of a hash), as the other CommState’s have an empty string as hash. If a new community comes into existence, the hashed state of a user does not need to change, because by default he won’t be part of it. However, instead of an empty string, a pre-defined non-empty string may be used, or the respective hash / string may be excluded from the calculation.

[0077] An identity owner (i.e., user) X can prove: “My state is H” as follows: X can provide a proof of owning Identity ID X to a challenger using proof P1 (e.g., the first proof of association with a cross-community identity). X can further provide a proof (P2) thatX’s state is H. The second proof P2 may include that X knows for all communities in the CCORSS system the usernames for the communities X is part of, by providing the usernames to the respective communities as input to a function and proving that given this data, the hashed state equals the hashed state value that is in the CCORSS smart contract as value for Identity ID X.

[0078] The algorithm to calculate the hashed state of a user X given a mapping of community names to usernames can be coded easily. For example, this function can be called HASHED STATE. A zero-knowledge proof can be created where the usernames are kept as private data and not revealed to the verifier: “I know a private set of community ids A1,A2,etc and a set ofcorresponding private set of usernames U1,U2,etc so that when they are put into the hashed state calculation algorithm for user with Identity ID X, the hashed state equals the value H”. Turning this into a zero-knowledge proving system, a zero-knowledge proof with public inputs X (Identity ID), A1, A2, etc. (community names) and H (Hashed State value of user X), and private inputs U1, U2, etc. can be created. The zero-knowledge proof to be created proves that the user inputting the data knows U1, U2, etc. such that HASHED STATE(X, [A1,A2,...],[U1,U2, ...]) = H where the values A1,A2, H and X are prefilled.

[0079] Accordingly, with respect to Figs. 1a to 1d, the second proof of non-membership in the community to be joined may use a set of hash values being verifiable against a hashed state stored for the cross-community identity in the smart contract or in another smart contract. For example, the act of verifying the second proof may comprise verifying the respective set of hashed values against the hashed state stored for the cross-community identity. In particular, verifying the second proof of non-membership in the community to be joined may comprise verifying that the second proof includes correct hash values of any user account identifier being associated with the cross-community identity. There are different ways of dealing with communities that the user is a non-member of, such as the community to be joined. For example, the proof may one of a) use a hash value derived from a default value for the user account identifier for the community to be joined, b) use a default hash value for the user account identifier for the community to be joined, or c) exclude a hash value for the user account identifier for the community to be joined.

[0080] The user is now part of Community A and is being scored on the different facets. The implementation of this reputation system is left to the community, though standard implementations may exist and can be reused across different communities. Either way, communities may have an API (Application Programming Interface) to view reputation scores for a user, and a way to generate on user demand a proof that a user meets certain criteria in a community. For example, Community A should be able to generate proofs according to the “helpful > 50 OR humor > 80” prescription for a certain user that anyone can validate. For example, community operational / public keys may be stored in a smart contract. With the combination of membership proofs (I belong to community A, C, E but not D) I satisfy primitive PR1 for A and primitive PR3 for E proofs, users can now be checked for onboarding. In other words, with respect to Figs. 1a to 1 d, the request may further comprise a third proof of the user fulfilling at least one reputation criterion in at least one further community.

[0081] In the following, examples are given with respect to proving that the user meets certain criteria in a community.A proof P3 of a username’s reputation score in community A may be performed as follows: If the user requests a reputation proof from a community that he or she is part of, the community may generate a document with the (hashed or cleartext) username in that community and the reputation scores and sign it with the private key of community. Because the public key of that community is in a smart contract, anyone can validate that the document is correct and untampered. Accordingly, verifying the third proof may comprise verifying a signature of the reputation score document against a public key of the respective further community. It proves that user U1 in community A1 has a certain reputation score set, but this username cannot be translated or correlated back to an Identity ID. Note that the correctness of contents of R can be validated on-chain because the public key of every community is also on-chain.

[0082] A proof P4 of a reputation score document from a community may be performed as follows: If a user wants to prove to the CCORSS system or any external verifier that his / her Identity ID X has reputation score document R in community A without revealing the username in community A, that means proving “I am Identity ID X (P1) + I know a username II for community A so that HASHED STATE matches H (P2)” where H is the value from the smart contract combined with P3: “Username U’s reputation score in community A is this document R.” In the combined proof system, the same U is used in P2 and P3. Now the user can prove “I am X and my reputation score document in community A is R”. The verifier only sees X and R, not the private data used to prove this: A1, A2, ..., U1, U2, ..., the private keys of the user or the community A. A verifier can use the public key of the Identity, the public key of the community A, the smart contract mapping of Identity ID to Hashed State. Accordingly, with reference to Figs. 1a to 1c, the third proof of the user fulfilling at least one reputation criterion in at least one further community may use a set of hash values being verifiable against a hashed state stored for the cross-community identity in the smart contract or in another smart contract, with the act of verifying the third proof comprising verifying the respective set of hashed values against the hashed state stored for the cross-community identity. For example, a reputation score document may include the following information:

[0083] Date: 10 / 01 / 2025 13:05:07T+01

[0084] Helpfulness: 95

[0085] Politeness: 50

[0086] Humor: 35

[0087] A proof P5 of meeting reputation score requirements for community B may be performed as follows. A reputation score document for an identity X in community A may be required to match a set of reputation score requirements Req1 , Req2, .... The user generating this proofuses proof P5 to prove to the onboarding mechanism of CCORSS or any external verifier that the reputation score requirements of community B are met. Reputation score requirements for a community can span multiple existing communities. In the following, the focus is on proving a reputation score requirement for one existing community A. If there are requirements for multiple existing communities, they can simply be combined - all of them may be required to satisfy the requirement, or perhaps the average of the scores may be required to meet criteria. It may be avoided to bring the entire reputation score document as this would allow reverse engineering of a user’s identity. Proof P5 might only include a proof about certain aspects of R, e.g., that it satisfies reputation score requirements primitives (e.g. helpfulness > 5). Several of these can be combined into a function that returns true or false, e.g., Req R) = (R. helpfulness > 5 AND R. politeness > 2). The previous proof P4 can be used as part of P5 as follows

[0088] The user knows a reputation document R, so that (P4 + R is a valid reputation score document for community A for a username that relates to the user’s identity X and Req(R)=true.

[0089] Thus, with reference to Figs. 1a to 1d, verifying the third proof of the user fulfilling at least one reputation criterion in at least one further community may comprise verifying that the third proof uses hash values that indicate that, for each of the at least one further community, there exists a reputation score document provided by the respective further community that adheres to a reputation requirement of the community to be joined. The reputation score document may be associated with a user account identifier for the respective further community. The user account identifier may be associated with the cross-community user identifier.

[0090] If there are multiple requirements Req1, Req2, etc. the combined proof of meeting reputation score requirements can be generated. If there are requirements about reputation in multiple existing communities, the proofs can be combined as highlighted above. It is noted that communities may also impose restrictions on the date issued in a document (recent enough). For the overall proof to be meaningful, it may also be proven that the Req1, Req2, etc. set of proofs being satisfied matches the requirements set by the community. Because the reputation score requirements are obtained from the community’s public endpoint, they may be signed and can be validated against the public key from the community that is stored on chain. Accordingly, verifying the third proof may comprise verifying a signature of the reputation requirement being used against a public key of the community to be joined. An on-chain verifier verifying the proof of meeting reputation score may validate that the requirements list is signed by the community the user is onboarding to.Similarly, users could be required to regularly re-demonstrate the community requirements policies while they are already active in the community (e.g., once per month or before launching a new discussion thread) by preserving updated timestamped proofs.

[0091] In some implementations, a further proof P6 of a new hashed state after onboarding to a community for which an identity matches the reputation requirements may be used. For a list operation in onboarding to a community B, after proving the identity ownership (first proof), existing community membership state (second proof) and meeting the reputation requirements (third proof), the user may prove how to obtain a new hashed state to be stored on chain, for the same set of usernames and community memberships as before with only one modification: the new username and community membership added. But since the new username should not be divulged, another zero-knowledge proof with private input may be used. For this, proof P2 may be used, and private inputs A1,A2, ... and U1, U2, ... that are used in the proof, and a proof may be furnished that, if only the tuple (An, Un) is changed, where n matches the community the user is joining, the HASHED STATE becomes the new state H2 (which the smart contract will need in the onboarding system). So, P6 includes proving P5 + that the user know a username so that the new HASHED STATE is H2, after changing only one community membership.

[0092] To prevent duplicate usernames in a community, usernames may be requested from the community’s endpoint and reserved prior to providing reputation proofs. The username may be signed and reserved by the new community and this signature may be included in P6. So the combined proof may be as follows:

[0093] P6 = P5 + the user knows a username U such that the new HASHED STATE is H2, after changing only one community membership + the public key that signed signature^) is the one from the community configuration smart contract.

[0094] In some implementations, a further proof P7 of owning a username U in community A may be used. After proving everything for onboarding and requesting a free username from the community that a user wants to join, the state on-chain is updated. The user may be required to prove their right to access the secret username that he reserved for usage in a community. This is mainly a proof P2 where one of the U’s is not private. Proof of community membership state for HASHED STATE, given secret inputs A1, A2, ... U1, U2, .. but public input B (community name joining), Ub (username for community B):

[0095] P7 = The user owns Identity ID X for which the current hashed state is H and a set of private usernames and community memberships where one is public: Ub (username for community B), and the state calculation algorithms gives Hashed state H.Note that this proof will NOT be used on chain, but on the community B endpoint. As such, the username can be correlated to the Identity ID X only by the administrators of the community B backend during the onboard call, and never after that. With respect to Figs. 1a to 1 d, the request may further comprise a fourth proof, and / or or the fourth proof may be provided separately to an endpoint of the community being joined as part of a further request. The fourth proof may be a proof of having acquired a user account identifier for the community to be joined. The request or further request may further comprise a new hashed state that represents membership and non-membership of the cross-community identity in the communities after joining the community to be joined.

[0096] In some examples, a further proof P8 of not yet being part of a community may be used. This is a variant of proof P2, where one of the inputs is not private and set to empty string. This proof may be used in onboarding - a user can only onboard if not already onboarded.

[0097] In the following, a detailed example of the proofs used in joining a community is provided. A user locally has the set of usernames for each of the communities he or she is part of. This is private data that will be used in proof generation but should not be publicly available as this would allow username correlation across communities. The user’s identity state can be updated as follows:

[0098] A user that wants to join community B may obtain a list of reputation requirements from the endpoint. The user may then request a proof of reputation RA, RB, etc. for each of the communities the user needs to prove reputation from. The user generates the proofs P5 for every reputation score requirement for every community. The user further generates proof P1 of owning identity X. The user further generates proof P2 of knowing all of the usernames and memberships for the user’s state H on chain. The user further generates proof P8 of not yet being part of community B. The user chooses a username lib to be known in community B. This may be done using web2 interaction with the community B to prevent duplicate usernames (as the user cannot take a username that is already taken). The user generates a new HASHED STATE H2 and generates a proof P6 about it. The user provides P1 , P2, P6, P8 and the set of proofs P5 (as part of the request) to the “onboarding” method of the smart contract of the CCORSS system. The CCORSS smart contract (e.g., the smart contract 105 being referred to in connection with Figs. 1a to 1 d) validates the proofs against the existing hashed state for the user, and when deemed valid, transitions the state of the user to the new hashed state value H2 from proof P6. The smart contract on chain now has the mapping of Identity ID X to value H2. In other words, the smart contract may be configured to update the data structure of the smart contract or of a further smart contract to use the new hashed statefor the cross-community identity. The user can now prove ownership of the username for community B with proof P7 and call the onboarding endpoint of community B with P7 and the new username lib. The backend verifies the proof and generates new login credentials for the user (e.g. password). The user can use these login credentials to onboard to community B.

[0099] In general, the data structure and proof system used may be designed with care. Hashing, salting, seed, and recovery may be added, and data structure may be made efficient. Care may be taken to make sure the required proofs can be generated, e.g., in a fast manner. In some examples, a measure of forgiveness may be implemented, by allowing forgiveness for communities or adding a time-history reduction function for older communities the user is no longer active in. In some examples, the ecosystem can be kickstarted by allowing a one-off “bring existing web2” reputation import from an online platform, such as Reddit.

[0100] The following examples pertain to further embodiments of the present disclosure:

[0101] (1) A node for a network hosting a distributed ledger, comprising:

[0102] at least one interface for communicating with other nodes of the network; and processor circuitry to execute a smart contract being hosted on the distributed ledger, the smart contract being configured to:

[0103] obtain a request of a user for joining a community associated with the smart contract, the request comprising at least a first proof of association with a cross-community identity and a second proof of non-membership in the community to be joined, verify the proofs included in the request, and

[0104] initiate a join procedure to add the user to the community to be joined if the verification of the proofs is successful.

[0105] (2) The node according to (1), wherein the request further comprises a third proof of the user fulfilling at least one reputation criterion in at least one further community.

[0106] (3) The node according to one of (1) or (2), wherein the second proof of non-member- ship in the community to be joined and / or a third proof of the user fulfilling at least one reputation criterion in at least one further community uses a set of hash values being verifiable against a hashed state stored for the cross-community identity in the smart contract or in another smart contract, with the act of verifying the second proof and / or the third proof comprising verifying the respective set of hashed values against the hashed state stored for the cross-community identity.(4) The node according to (3), wherein the hashed state stored for the cross-community identity is based on a combination of one or more hash values being based on any user account identifier being associated with the cross-community identity.

[0107] (5) The node according to (4), wherein verifying the second proof of non-membership in the community to be joined comprises verifying that the second proof includes correct hash values of any user account identifier being associated with the cross-community identity, with the proof one of a) using a hash value derived from a default value for the user account identifier for the community to be joined, b) using a default hash value for the user account identifier for the community to be joined, or c) excluding a hash value for the user account identifier for the community to be joined.

[0108] (6) The node according to one of (4) or (5), wherein verifying the third proof of the user fulfilling at least one reputation criterion in at least one further community comprises verifying that the third proof uses hash values that indicate that, for each of the at least one further community, there exists a reputation score document provided by the respective further community that adheres to a reputation requirement of the community to be joined, with the reputation score document being associated with a user account identifier for the respective further community, with the user account identifier being associated with the cross-community user identifier.

[0109] (7) The node according to (6), wherein verifying the third proof comprises verifying a signature of the reputation score document against a public key of the respective further community.

[0110] (8) The node according to one of (6) or (7), wherein verifying the third proof comprises verifying a signature of the reputation requirement being used against a public key of the community to be joined.

[0111] (9) The node according to one of (1) to (8), wherein verifying the first proof of association with the cross-community identity comprises verifying a signature generated using a private key associated with the cross-community identity against a public key associated with the cross-community identity.

[0112] (10) The node according to one of (1) to (9), wherein the request further comprises a fourth proof of having acquired a user account identifier for the community to be joined, and a new hashed state that represents membership and non-membershipof the cross-community identity in the communities after joining the community to be joined, wherein the smart contract is configured to update a data structure of the smart contract or of a further smart contract to use the new hashed state for the cross-community identity, the data structure representing the membership and nonmembership of cross-community identities in the communities associated with the smart contract.

[0113] (11) The node according to one of (1) to (10), wherein at least one of the proofs is a zeroknowledge proof.

[0114] (12) The nodes according to one of (1) to (11), wherein the smart contract is configured to maintain a data structure representing the membership and non-membership of cross-community identities in the communities associated with the smart contract, with the data structure comprising, for each cross-community identity, a hashed state representing the membership and non-membership of the cross-community identity in the communities associated with the smart contract.

[0115] (13) The node according to (12), wherein the data structure comprises at least one Merkle tree for calculating proofs to be verified against the hashed state of the respective cross-community identity.

[0116] (14) The node according to one of (12) or (13), wherein the smart contract is configured to register a new cross-community identity by adding the cross-community identity to the data structure, with the data structure initially indicating that the newly registered cross-community identity is non-member in any community associated with the smart contract.

[0117] (15) The node according to (14), wherein the act of registering the new cross-community identity comprises verifying that a user registering the cross-community identity is a human and that the human is previously unregistered at the data structure.

[0118] (16) A node for a network hosting a distributed ledger, comprising:

[0119] at least one interface for communicating with other nodes of the network; and processor circuitry to execute a smart contract being hosted on the distributed ledger, the smart contract being configured to:

[0120] maintain a data structure representing the membership and non-membership of cross-community identities in communities associated with the smart contract, withthe data structure comprising, for each cross-community identity, a hashed state representing the membership and non-membership of the cross-community identity in the communities associated with the smart contract, and

[0121] provide, upon request, the hashed value representing the membership and nonmembership of a cross-community identity in a community of the communities associated with the smart contract.

[0122] (17) A method for a node for a network hosting a distributed ledger, the method comprising:

[0123] obtaining, by a smart contract being executed by the node, a request of a user for joining a community associated with the smart contract, the request comprising at least a first proof of association with a cross-community identity and a second proof of non-membership in the community to be joined;

[0124] verifying, by the smart contract, the proofs included in the request; and initiating, by the smart contract, a join procedure to add the user to the community to be joined if the verification of the proofs is successful.

[0125] (18) A method for a node for a network hosting a distributed ledger, the method comprising:

[0126] Maintaining, by a smart contract, a data structure representing the membership and non-membership of cross-community identities in communities associated with the smart contract, with the data structure comprising, for each cross-community identity, a hashed state representing the membership and non-membership of the crosscommunity identity in the communities associated with the smart contract; and Providing, upon request, the hashed value representing the membership and nonmembership of a cross-community identity in a community of the communities associated with the smart contract.

[0127] (19) A non-transitory, computer-readable medium comprising a program code that, when the program code is executed on a processor, a computer, or a programmable hardware component, causes the processor, computer, or programmable hardware component to perform the method of (17).

[0128] (20) A non-transitory, computer-readable medium comprising a program code that, when the program code is executed on a processor, a computer, or a programmable hardware component, causes the processor, computer, or programmable hardware component to perform the method of (18).The aspects and features described in relation to a particular one of the previous examples may also be combined with one or more of the further examples to replace an identical or similar feature of that further example or to additionally introduce the features into the further example.

[0129] Examples may further be or relate to a (computer) program including a program code to execute one or more of the above methods when the program is executed on a computer, processor or other programmable hardware component. Thus, steps, operations or processes of different ones of the methods described above may also be executed by programmed computers, processors or other programmable hardware components. Examples may also cover program storage devices, such as digital data storage media, which are machine-, processor- or computer-readable and encode and / or contain machine-executable, processorexecutable or computer-executable programs and instructions. Program storage devices may include or be digital storage devices, magnetic storage media such as magnetic disks and magnetic tapes, hard disk drives, or optically readable digital data storage media, for example. Other examples may also include computers, processors, control units, (field) programmable logic arrays ((F)PLAs), (field) programmable gate arrays ((F)PGAs), graphics processor units (GPU), application-specific integrated circuits (ASICs), integrated circuits (ICs) or system-on-a-chip (SoCs) systems programmed to execute the steps of the methods described above.

[0130] It is further understood that the disclosure of several steps, processes, operations or functions disclosed in the description or claims shall not be construed to imply that these operations are necessarily dependent on the order described, unless explicitly stated in the individual case or necessary for technical reasons. Therefore, the previous description does not limit the execution of several steps or functions to a certain order. Furthermore, in further examples, a single step, function, process or operation may include and / or be broken up into several sub-steps, -functions, -processes or -operations.

[0131] If some aspects have been described in relation to a device or system, these aspects should also be understood as a description of the corresponding method. For example, a block, device or functional aspect of the device or system may correspond to a feature, such as a method step, of the corresponding method. Accordingly, aspects described in relation to a method shall also be understood as a description of a corresponding block, a correspondingelement, a property or a functional feature of a corresponding device or a corresponding system.

[0132] The following claims are hereby incorporated in the detailed description, wherein each claim may stand on its own as a separate example. It should also be noted that although in the claims a dependent claim refers to a particular combination with one or more other claims, other examples may also include a combination of the dependent claim with the subject matter of any other dependent or independent claim. Such combinations are hereby explicitly proposed, unless it is stated in the individual case that a particular combination is not in-tended. Furthermore, features of a claim should also be included for any other independent claim, even if that claim is not directly defined as dependent on that other independent claim.

Claims

ClaimsWhat is claimed is:

1. A node for a network hosting a distributed ledger, comprising:at least one interface for communicating with other nodes of the network; and processor circuitry to execute a smart contract being hosted on the distributed ledger, the smart contract being configured to:obtain a request of a user for joining a community associated with the smart contract, the request comprising at least a first proof of association with a cross-community identity and a second proof of non-membership in the community to be joined,verify the proofs included in the request, andinitiate a join procedure to add the user to the community to be joined if the verification of the proofs is successful.

2. The node according to claim 1 , wherein the request further comprises a third proof of the user fulfilling at least one reputation criterion in at least one further community.

3. The node according to claim 1, wherein the second proof of non-membership in the community to be joined and / or a third proof of the user fulfilling at least one reputation criterion in at least one further community uses a set of hash values being verifiable against a hashed state stored for the cross-community identity in the smart contract or in another smart contract, with the act of verifying the second proof and / or the third proof comprising verifying the respective set of hashed values against the hashed state stored for the cross-community identity.

4. The node according to claim 3, wherein the hashed state stored for the crosscommunity identity is based on a combination of one or more hash values being based on any user account identifier being associated with the cross-community identity.

5. The node according to claim 4, wherein verifying the second proof of non-membership in the community to be joined comprises verifying that the second proof includes correct hash values of any user account identifier being associated with the cross-community identity, with the proof one of a) using a hash value derivedfrom a default value for the user account identifier for the community to be joined, b) using a default hash value for the user account identifier for the community to be joined, or c) excluding a hash value for the user account identifier for the community to be joined.

6. The node according to claim 4, wherein verifying the third proof of the user fulfilling at least one reputation criterion in at least one further community comprises verifying that the third proof uses hash values that indicate that, for each of the at least one further community, there exists a reputation score document provided by the respective further community that adheres to a reputation requirement of the community to be joined, with the reputation score document being associated with a user account identifier for the respective further community, with the user account identifier being associated with the cross-community user identifier.

7. The node according to claim 6, wherein verifying the third proof comprises verifying a signature of the reputation score document against a public key of the respective further community.

8. The node according to claim 6, wherein verifying the third proof comprises verifying a signature of the reputation requirement being used against a public key of the community to be joined.

9. The node according to claim 1 , wherein verifying the first proof of association with the cross-community identity comprises verifying a signature generated using a private key associated with the cross-community identity against a public key associated with the cross-community identity.

10. The node according to claim 1, wherein the request further comprises a fourth proof of having acquired a user account identifier for the community to be joined, and a new hashed state that represents membership and non-membership of the cross-community identity in the communities after joining the community to be joined, wherein the smart contract is configured to update a data structure of the smart contract or of a further smart contract to use the new hashed state for the cross-community identity, the data structure representing the membership and non-membership of cross-community identities in the communities associated with the smart contract.

11. The node according to claim 1, wherein at least one of the proofs is a zeroknowledge proof.

12. The nodes according to claim 1 , wherein the smart contract is configured to maintain a data structure representing the membership and non-membership of crosscommunity identities in the communities associated with the smart contract, with the data structure comprising, for each cross-community identity, a hashed state representing the membership and non-membership of the cross-community identity in the communities associated with the smart contract.

13. The node according to claim 12, wherein the data structure comprises at least one Merkle tree for calculating proofs to be verified against the hashed state of the respective cross-community identity.

14. The node according to claim 12, wherein the smart contract is configured to register a new cross-community identity by adding the cross-community identity to the data structure, with the data structure initially indicating that the newly registered cross-community identity is non-member in any community associated with the smart contract.

15. The node according to claim 14, wherein the act of registering the new crosscommunity identity comprises verifying that a user registering the cross-community identity is a human and that the human is previously unregistered at the data structure.

16. A node for a network hosting a distributed ledger, comprising:at least one interface for communicating with other nodes of the network; and processor circuitry to execute a smart contract being hosted on the distributed ledger, the smart contract being configured to:maintain a data structure representing the membership and non-membership of cross-community identities in communities associated with the smart contract, with the data structure comprising, for each cross-community identity, a hashed state representing the membership and non-membership of the cross-community identity in the communities associated with the smart contract, andprovide, upon request, the hashed value representing the membership and nonmembership of a cross-community identity in a community of the communities associated with the smart contract.

17. A method for a node for a network hosting a distributed ledger, the method comprising:obtaining, by a smart contract being executed by the node, a request of a user for joining a community associated with the smart contract, the request comprising at least a first proof of association with a cross-community identity and a second proof of non-membership in the community to be joined;verifying, by the smart contract, the proofs included in the request; andinitiating, by the smart contract, a join procedure to add the user to the community to be joined if the verification of the proofs is successful.

18. A method for a node for a network hosting a distributed ledger, the method comprising:Maintaining, by a smart contract, a data structure representing the membership and non-membership of cross-community identities in communities associated with the smart contract, with the data structure comprising, for each cross-community identity, a hashed state representing the membership and non-member- ship of the cross-community identity in the communities associated with the smart contract; andProviding, upon request, the hashed value representing the membership and nonmembership of a cross-community identity in a community of the communities associated with the smart contract.

19. A non-transitory, computer-readable medium comprising a program code that, when the program code is executed on a processor, a computer, or a programmable hardware component, causes the processor, computer, or programmable hardware component to perform the method of claim 17.

20. A non-transitory, computer-readable medium comprising a program code that, when the program code is executed on a processor, a computer, or a programmable hardware component, causes the processor, computer, or programmable hardware component to perform the method of claim 18.

Images