Patent Description:
Blockchains are typically permissionless. Since anyone can join a blockchain anonymously and without any permission requirement, the peers must be considered as untrusted. The peers are identified by a unique wallet address which does not reveal a true identity of a respective owner. Hence, owners can create as many wallets as they desire. A dishonest user willing to disrupt the blockchain could easily create <NUM>% or more of identities to control a majority of identities known to the blockchain. This is called a Sybil Attack. Therefore, blockchains cannot simply consider every identity as equal. In result, different ways are needed in the assigning voting rights to identities in order to come to consensus about the blockchain state to establish trust.

Particular consensus algorithms are developed, particularly a proof-of-work consensus algorithm and a proof-of-stake consensus algorithm. In the proof-of-work consensus algorithm, an identity needs to spend processing resources in order to gain voting rights. In the proof-of-stake consensus algorithm, an identity gains voting rights proportional to a number of blockchain-native tokens the associated wallet puts in escrow, which they risk losing if caught cheating.

The proof of work consensus algorithm suffers from significant energy requirement. The proof of stake consensus algorithm gives an unfair advantage to those with a financial advantage, since the more money one puts down, the more voting rights that person obtains. Hence, the proof of stake consensus algorithm may suffer from insufficient resistance capability against pooling of voting rights regarding the state of the blockchain.

The scope of protection sought for various embodiments is set out by the independent claims. The embodiments and features, if any, described in this specification that do not fall under the scope of the independent claims are to be interpreted as examples useful for understanding various embodiments.

According to a first example aspect, there is provided a method for validating a new validator for a proof-of-origin, PoO, blockchain comprising.

The authorised signer may be registered in the PoO blockchain as the authorised signer by the operator. The identifier of the new validator may comprise a public key of the new validator or a derivative of the public key of the new validator.

The identifier of the authorised signer may comprise a public key of the authorised signer or a derivative of the public key of the authorised signer.

The checking of the cryptographic signature of the authorised signer may comprise using a public key of the authorised signer corresponding to a private key with which the cryptographic signing has been performed.

The announce message may further comprise a cryptographic signature of the new validator over at least a nonce and optionally over the peer identifier;.

The nonce may comprise a timestamp, a random code, and / or a sequence number. The nonce may comprise a derivative of the timestamp, the random code, and / or the sequence number. The derivative may be a unidirectional derivative. The derivative may be a cyclic redundance sum.

The checking of the cryptographic signature of the new validator may comprise using a public key of the new validator corresponding to a private key with which the cryptographic signing has been performed.

The unique tag may comprise a one-directional cryptographic hash of at least a unique device identifier and port used by a piece of hardware with which a fixed communication line is communicatively connected to the sender of the announce message for registering the new validator onto the PoO blockchain. This sender is also referred to as the owner of the new validator. The piece of hardware may be an access point. The piece of hardware may comprise at least <NUM> or at least <NUM> ports for different landlines, for providing connections with respective customer premise equipment.

The method may further comprise on accepting the new validator for the PoO blockchain, overwriting a previous mapping of the unique tag in the PoO blockchain with a new mapping. This overwriting limiting the number of validator registrations per unique tag to one. Alternatively, rather than overwriting, another embodiment could simply reject the new announcement if the unique tag of the new announcement is already registered on chain. In yet another embodiment, a fixed sufficiently small number, e.g., <NUM> or <NUM> of registrations per unique tag could be allowed to allow multiple people in a single household to each register their own validator, or to support situations in which multiple households reside in a single residence.

The announce message may further comprise a geographic indication of a location of the sender of the announce message for registering the new validator onto the PoO blockchain.

The cryptographic signature of the authorised signer may further extend over the geographic indication.

The geographic indication may be coarse grained to reduce spatial accuracy of the geographic indication.

According to a second example aspect, there is provided a method for announcing a new validator to a proof-of-origin, PoO, blockchain, comprising:.

The method may further comprise obtaining a PoO attestation for the new validator by generating the PoO attestation for the new validator.

The method may further comprise generating the PoO attestation in two phases so that first a customer premises equipment produces a third cryptographic signature and subsequently the access point of the fixed line operator verifies the third cryptographic signature replaces that with the second cryptographic signature, if the third cryptographic signature was correct.

The method may further comprise obtaining a PoO attestation for the new validator from an authorised signer.

The receiving of the announce request may be performed using a web server.

The method may further comprise obtaining and verifying an announce request authenticator as a condition for at least one of the obtaining the attestation, containing the attestation in the announce message, or sending the announce message to the existing validators. The authenticator may comprise or be a subscription identifier of the fixed communication operator. The authenticator may comprise or be a dedicated identifier issued by the fixed communication operator for a subscriber of the fixed communication operator.

The method may further comprise obtaining the unique tag from the fixed communication operator.

The method may further comprise maintaining a mapping from a current Internet address of the validator and the unique tag.

The unique tag may be obtained based on the mapping from the current IP address for the generating of the PoO attestation.

The method may further comprise sending an operator registration request to the PoO blockchain by the operator for gaining authority to attest PoO validators to the PoO blockchain. The operator registration request may comprise a certification authority issued attestation of the operator. The operator registration request may comprise public address of the operator. The public address may comprise a public key of the operator.

The method may further comprise providing an operator stake token by the operator to the PoO blockchain by the operator for securing reliability of the operator.

The method may further comprise performing network assertion to repeatedly verify approximate location or network residence of different validators. The network assertion may be performed using an internet latency test. The network assertion may be performed using a route tracing test to obtain records of different validators for cross-referencing.

According to a third example aspect, there is provided a method for registering a user device as a new validator to a proof-of-origin, PoO, blockchain, comprising:.

The causing of the transmission of the PoO announce message may comprise sending the announce request using a hypertext transfer protocol, HTTP, protocol for interception and addition of the PoO attestation in the fixed communication network of the operator.

The causing of the transmission of the PoO announce message may comprise requesting addition of the PoO attestation from a PoO web server in the fixed communication network of the operator.

According to a fourth example aspect, there is provided an announce message for announcing a new validator to a proof-of-origin, PoO, blockchain, comprising:.

According to a fifth example aspect, there is provided a signal comprising the announce message of the fourth example aspect.

According to a sixth example aspect, there is provided a computer program comprising computer executable program code configured to execute the method of the first, second, or third example aspect.

According to a seventh example aspect, there is provided an apparatus comprising at least one processor; and at least one memory including computer program code; the at least one memory and the computer program code configured to, with the at least one processor, cause the apparatus at least to perform the method of the first example aspect.

According to an eighth example aspect, there is provided an apparatus comprising a processor configured to perform the method of the first example aspect.

According to a ninth example aspect, there is provided an apparatus comprising means for performing the method of the first example aspect.

According to a tenth example aspect, there is provided an apparatus comprising a memory and a processor that are configured to cause the apparatus to perform the method of the first example aspect.

According to an eleventh example aspect, there is provided an apparatus comprising at least one processor; and at least one memory including computer program code; the at least one memory and the computer program code configured to, with the at least one processor, cause the apparatus at least to perform the method of the first example aspect.

According to a twelfth example aspect, there is provided an apparatus comprising at least one processor; and at least one memory including computer program code; the at least one memory and the computer program code configured to, with the at least one processor, cause the apparatus at least to perform the method of the second example aspect.

According to a thirteenth example aspect, there is provided an apparatus comprising a processor configured to perform the second example aspect.

According to a fourteenth example aspect, there is provided an apparatus comprising means for performing the method of the second example aspect.

According to a fifteenth example aspect, there is provided an apparatus comprising a memory and a processor that are configured to cause the apparatus to perform the method of the second example aspect.

According to a sixteenth example aspect, there is provided an apparatus comprising at least one processor; and at least one memory including computer program code; the at least one memory and the computer program code configured to, with the at least one processor, cause the apparatus at least to perform the method of the second example aspect.

According to a seventeenth example aspect, there is provided an apparatus comprising at least one processor; and at least one memory including computer program code; the at least one memory and the computer program code configured to, with the at least one processor, cause the apparatus at least to perform the method of the third example aspect.

According to an eighteenth example aspect, there is provided an apparatus comprising a processor configured to perform the method of the third example aspect.

According to a nineteenth example aspect, there is provided an apparatus comprising means for performing the method of the third example aspect.

According to a twentieth example aspect, there is provided an apparatus comprising a memory and a processor that are configured to cause the apparatus to perform the method of the third example aspect.

According to a twenty first example aspect, there is provided an apparatus comprising at least one processor; and at least one memory including computer program code; the at least one memory and the computer program code configured to, with the at least one processor, cause the apparatus at least to perform the method of the third example aspect.

According to a twenty second example, there is provided a system. The system may comprise the apparatus of any of the seventh to eleventh example aspect. The system may comprise the apparatus of any of the twelfth to sixteenth example aspect. The system may comprise the apparatus of any of the seventeenth to twenty first example aspect.

Any foregoing memory medium may comprise a digital data storage such as a data disc or diskette, optical storage, magnetic storage, holographic storage, opto-magnetic storage, phase-change memory, resistive random access memory, magnetic random access memory, solid-electrolyte memory, ferroelectric random access memory, organic memory, or polymer memory. The memory medium may be formed into a device without other substantial functions than storing memory or it may be formed as part of a device with other functions, including but not limited to a memory of a computer, a chip set, and a sub assembly of an electronic device.

The embodiments in the foregoing are used merely to explain selected aspects or steps that may be utilised in implementations.

For a more complete understanding of example embodiments, reference is now made to the following descriptions taken in connection with the accompanying drawings in which:.

An example embodiment and its potential advantages are understood by referring to <FIG> of the drawings. In this document, like reference signs denote like parts or steps.

<FIG> shows an architectural drawing of a wired network topology of an example embodiment. From left to right, <FIG> shows an end-user home <NUM> where the user can use a computing device <NUM> to connect to the internet <NUM>. This computing device <NUM> is connected via her customer premise equipment, CPE, <NUM>, such as her home router. In an example embodiment, this connection is wired, (e.g., using an ethernet cable) or wireless, (e.g., using wireless local area network, WLAN. The CPE <NUM> is physically connected over a customer premise connection <NUM> to operator equipment. In an example embodiment, the customer premise connection <NUM> is connected to a given physical location. In an example embodiment, the customer premise connection <NUM> comprises a wired medium such as a twisted copper pair, a coaxial cable, or an optical fibre. In an example embodiment, the customer premise connection <NUM> comprises a wireless connection, such as a directional WLAN, a free-space optical communication link, or microwave communications link.

In an example embodiment, the operator equipment is hosted in a street cabinet <NUM> near the user's home <NUM>. In an example embodiment, the one street cabinet <NUM> physically connects tens or hundreds of home connection cables, each cable providing service fixed communication connectivity (e.g., internet access, telephony) to one customer or more particularly to one termination point. Notably, one home or commercial premise may have two or more termination points. In an example embodiment, the termination point refers to a point at which the CPE is connectable or where a communication device of the customer is connectable to the Internet via the operator equipment. For example, the termination port may be implemented as a wall socket that is connected to one of the ports of a network switch in a technical room of a business or residential building.

In an example embodiment, the street cabinet <NUM> connects the termination points and an associated operator access network <NUM> with a termination point circuitry <NUM>. In an example embodiment, the operator access network <NUM> is further connected through a core network connection <NUM> with a core network <NUM> of the operator. In an example embodiment, the core network <NUM> has an Internet connection <NUM> to the internet <NUM>.

The access network <NUM> maintains configuration data identifying which physical link <NUM>, and hence subscriber, initiated a given communication, such as an IP packet-based transmission. Therefore, the operator possesses a unique and tamper-resistant identification of the original initiator of the traffic. However, this tamper-resistant identification is generally not available beyond the core network of the operator. When a data transmission reaches a destination on some Internet-connected server, this knowledge is lost and so not available. The source IP address remains, but that address is easily spoofed and does not identify the original sender in case of redirecting her data traffic, e.g., via a virtual private network, VPN, tunnel, or via a proxy server.

<FIG> shows a wired network topology of another example embodiment. Three buildings <NUM>, <NUM>, <NUM> each have a limited number of households at physical ports <NUM>, <NUM>, <NUM> on operator-owned access nodes <NUM>, <NUM>. In an example embodiment, one or more of the access nodes <NUM>, <NUM> is a digital subscriber line access multiplexer, DSLAM. In an example embodiment, one or more of the access nodes <NUM>, <NUM> is deployed at street cabinets <NUM>, <NUM>. In an example embodiment, one physical subscriber line, such as an optical fibre, is multiplexed. For example, one optical fibre may connect all apartments of a block of flats or all operator lines of one office building with a local switch configured to divide the multiplexed connections to each separate subscriber connection point, such as wall sockets. Functionally, each such intermediately multiplexed connection to separate subscriber connection points is seen as one fixed connection of the operator.

The access nodes <NUM>, <NUM> provide respective customer premise connections <NUM>, <NUM>, <NUM> for different customers, here depicted as separate households, each equipped with a respective CPE <NUM>, <NUM>, <NUM>.

<FIG> further illustrates home networks <NUM>, <NUM>, <NUM> including respective end-user devices with Internet connectivity, such as personal computers, mobile phones, tablets, Internet of Things devices, etc. In an example embodiment, the end user devices are connected to respective home routers <NUM>, <NUM>, <NUM>, via a wired connections, such as the ethernet, or a wireless connection, such as the WLAN, <NUM>, <NUM>, <NUM> respectively. The home routers <NUM>, <NUM>, <NUM> terminate a "last mile" of fixed lines at the other end of the access nodes. The home routers can be seen as a first point of access into the operator network. Other routers and/or switches could additionally be deployed in a home network, but that is irrelevant for the present discussion. Ultimately, all network traffic originating from an end-user device in the home and destined for the Internet <NUM>, passes through the home router <NUM>, <NUM>, <NUM> and over the customer premise connections <NUM>, <NUM>, <NUM> towards the access node <NUM>, <NUM> of the operator.

As drawn in <FIG>, In an example embodiment, the access nodes <NUM>, <NUM> aggregate internet traffic for a limited number of households <NUM>, <NUM>, <NUM>. In an example embodiment, the access nodes <NUM>, <NUM> are deployed geographically close to the households they serve. As such, the access nodes <NUM>, <NUM> act as a proxy for limited real-estate available in a geographical area and can therefore be seen as a scarce resource.

In <FIG>, <FIG> ports are drawn per access node <NUM>, <NUM> for simplicity. In an example embodiment, one access node has hundreds of ports. Moreover, <FIG> simplifies an entire operator network ultimately providing Internet access <NUM> as outlined in <FIG>, and focusses on the physical termination of physical lines, i.e., wires reaching into the subscriber premises, aka the last mile.

In an example embodiment, there is provided a PoO blockchain. The security of the blockchain is assured by assigning a sufficiently large set of validator nodes, which check the validity and order of transactions (e.g., monetary transfers, ownership records, etc.) that are submitted by different blockchain users. The validator nodes can propose new blocks of validated transactions to their peers, i.e., other validator nodes, by broadcasting a new block on a peer-to-peer network interconnecting all the validators. The validator nodes also check the validity of blocks proposed by other validators. A distributed consensus algorithm of the blockchain dictates that validators should follow the longest chain of validated blocks and add proposed valid blocks to that chain.

In order to avoid any one validator node proposing a disproportionate number of blocks to the blockchain in comparison to that of other validator nodes, the consensus algorithm requires the validators to be randomly chosen to be allowed to propose a block. If a proof-of-work consensus algorithm were used, all validators would race to first find an answer to a cryptographic puzzle. On the other hand, if a proof-of-stake algorithm were used, a randomly chosen subset of validators would be allowed to mutually agree on the next block. The voting rights would be proportional to the number of tokens being staked. A probability of being elected to the consensus group is proportional to the number of votes and therefore also proportional to the stake.

In an example embodiment, a proof-of-origin algorithm is used to choose proper validators. This differs from prior known consensus algorithms. Here, voting rights are directly linked to a scarce resource that is linked to physical property resources, i.e., real-estate with fixed communication lines.

In an example embodiment illustrated by <FIG>, a Proof-of-Origin, PoO enabled blockchain <NUM> requires a validator node <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM> to be announced through the HTTP(S) request <NUM> to a blockchain peer-to-peer network <NUM>.

Each validator node <NUM>. <NUM> has a unique cryptographic keypair <NUM>. <NUM> associated with that validator node. In each keypair <NUM>. <NUM> there is a public key and a private key. The public key acts as a unique identification of that validator, also called peer address. Each validator stores a copy of the blockchain state <NUM>. During the announcement procedure, a PoO attestation is generated for the user in question, or more accurately, for a current user of a given fixed communication line. In an example embodiment, the PoO attestation is automatically attached to the announcement request by request interception logic <NUM> running on operator owned equipment <NUM>.

In an example embodiment, the operator owned equipment is or comprises any of the CPE; a Home Router; equipment in the street cabinet such as a DSLAM, optical network terminal ONT; equipment in the access network, e.g., broadband remote access server, BRAS, ONT; or equipment in the core network of the operator. Here, this operator owned equipment is referred to as an access point AP <NUM>.

In an example embodiment, the announce request needs to be sent from the home network of the fixed communication operator so that the announce request can be intercepted and extended with the PoO attestation. Later, when the validator has been accepted to operate in the PoO blockchain (i.e., to produce blocks to the PoO blockchain), no more interception is required, and the validator node of the user can be used through any Internet connection. The registration process (commenced with announce request) happens only once for one validator node. In an example embodiment, it is required to refresh the attestation. For example, the attestation may comprise an expiration date after which the validator node would no longer be accepted in the PoO blockchain. In an example embodiment, the operator announces a cancellation of the validator to the PoO blockchain, e.g., by storing a new element to an exclusion or invalidation list in the PoO blockchain. The operator can thus cancel a validator of a user when the user moves out of premises of the operator or ceases to subscribe a connection from the operator.

In order to enable the user to submit the announcement request, the user, or owner as in <FIG>, sends an announcement message <NUM> from her device, announce validator node, to register herself to a proof-of-origin blockchain in a validator node registration procedure of an example embodiment. In an example embodiment, the announcement message <NUM> comprises an HTTP proof-of-origin, PoO, request header <NUM> shown in <FIG>. In an example embodiment, the PoO request header comprises a peer identifier <NUM> of the owner, peer@, such as a peer address of the owner or a validator node public key of the owner or a public address derived from the public key, or some other derived identifier of the owner. In an example embodiment, the request PoO request header further comprises a nonce n <NUM>. In an example embodiment, the request PoO request header further comprises a first signature S1 <NUM>, over the aforementioned peer identifier <NUM> and the nonce n <NUM>. The first signature S1 <NUM> is produced using a private key of the owner. In an example embodiment, the owner identifier is a public key or a derivative of the public key corresponding to the private key of the owner that is used in producing the first signature S1 <NUM>.

In an example embodiment, the nonce n <NUM> is or comprises a timestamp, a random code, and / or a sequence number. In an example embodiment, the nonce n <NUM> is or comprises a derivative of the timestamp, the random code, and / or the sequence number. In an example embodiment, the derivative is a unidirectional derivative. In an example embodiment, the derivative is a cyclic redundance sum.

After obtaining the PoO request header from the user and successfully verifying the first signature, the operator produces the PoO attestation <NUM> based on this PoO request header and tamper protection provided by cryptographic signatures of the user and the attestation provider, see <FIG>. In an example embodiment, the PoO attestation <NUM> is generated based on origin attestation data concerning the user. The PoO attestation <NUM> and the PoO request header <NUM> are contained within a PoO attestation header <NUM>.

In an example embodiment, the origin attestation data comprise a unique tag <NUM>, T. The unique tag T <NUM> is derived from at least a unique equipment Id (AP), and the port assigned to the user and used by the user for her fixed line communications. In an example embodiment, the unique tag T <NUM> is derived using a unidirectional hash designed to mitigate reverse derivation. In an example embodiment, the unique tag T <NUM> is derived using encryption. In an example embodiment, the unique tag T <NUM> comprises an autonomous system number ASN assigned by an internet assigned numbers authority, IANA, for the access point and a port identifier of a port assigned to a respective fixed communication line.

In an example embodiment, the origin attestation data comprise a geographical identifier G <NUM> indicative of region where a user device <NUM> resides. The geographical identifier G <NUM> may encode the geographical area in which the access point AP <NUM> is located, e.g., for allowing geographical information to be used by the consensus algorithm if that algorithm attempts to assure a sufficient geographical spread or focus among the members of a consensus group. In an example embodiment, the geographical information is coarse grained, such as reflecting only country, state, city, or a geographical region level such as a region of <NUM> x <NUM> or <NUM> x <NUM>.

In an example embodiment, the origin attestation data comprise an identifier <NUM> of an authorised signer. In an example embodiment, the identifier <NUM> of the authorised signer identifies an account usable by the operator to sign the attestation <NUM>. In an example embodiment, a set of authorised operators and / or their respective identifiers are stored in a chain variable, which can be consulted by anyone on the PoO blockchain. In an example embodiment, each authorised operator is allowed to register authorised signers on the PoO blockchain, e.g., one or more authorised signers per access point AP <NUM> owned by the operator. In an example embodiment, an authorised signer is dedicated to a given CPE.

In an example embodiment, the origin attestation data comprise a signature <NUM> of the authorised signer S2 over the peer identifier peer@ <NUM> of the owner, the nonce n <NUM>, the first signature S1 <NUM>, the unique tag T <NUM>, the geographical identifier G <NUM>, and optionally over the identifier <NUM> of the authorised signer. The PoO attestation may cryptographically attest that the data announced by the user device <NUM> are verified correct by the operator.

In an example embodiment, the data of the PoO request header <NUM> of <FIG> are obtained from a payload field of a PoO attestation request instead of a header. Likewise, in some example embodiments, other header data fields are conveyed in a payload. The use of header data fields may simplify processing in some cases, whereas the use of payload as a carrier for various data fields may facilitate some header conversions, error correction, error detection, and / or compliance with header size restrictions that could be applied in some parts of the Internet.

In different embodiments, the access point <NUM> is implemented by different entities, such as the CPE, a home router, equipment in the street cabinet, e.g., DSLAM, ONT, equipment in the access network, e.g., BRAS, ONT, or equipment in the core network of the operator.

In an example embodiment, the user device <NUM> is used to announce a validator node <NUM> and run the validator node <NUM>. In an example embodiment, it need not be the same device that announces the validator node and runs the validator node. Instead, a different device runs the validator node. It suffices that the validator node is provided with an account under which the validator node is running i.e., the public key part of the keypair <NUM> of the validator node and that this account is associated with a valid proof-of-origin attestation and registered on the PoO blockchain.

As mentioned in the foregoing, the announcement message <NUM> of <FIG> is sent as an HTTP request so that the access point <NUM> can intercept the request based on its headers (See <FIG>, ref. sign <NUM>). As mentioned in the foregoing, the announcement message <NUM> passing through the request interception logic <NUM> can be intercepted and modified. On noticing the PoO request header in a received HTTP request, the request interception logic <NUM> replaces that PoO request header with PoO attestation header, before routing it onwards to its destination <NUM>, the peer-to-peer network powering the PoO blockchain. In another example embodiment illustrated by <FIG>, the intercepting and an associated (deep packet) inspection can be avoided by making use of an explicit HTTP(S) request to a PoO module <NUM> running on equipment such as the CPE <NUM> and receiving a valid PoO attestation in response. With the PoO attestation, the owner can then send an HTTP(S) request that includes a valid PoO request header, for announcing the validator node of the owner in her sub-network <NUM> to a proof-of-origin-enabled peer. The embodiment shown by <FIG> supports both interception and web server methods so the user device <NUM> can use either one.

<FIG> shows a flow chart illustrating operation of a method of an example embodiment in the access point AP <NUM>, comprising one or more of:.

If the access point AP <NUM> is a router, then the passing may comprise routing the IP packet or the modified IP packet.

<FIG> shows a flow chart of a method of an example embodiment for verification of a new validator by blockchain peers. The method comprises one or more of: <NUM>. A validator node <NUM>. <NUM> in the blockchain peer-to-peer-network <NUM> receives the announcement <NUM> containing the PoO attestation header <NUM>.

The validator node <NUM>. <NUM> in question verifies signatures in the attestation header.

The validator node <NUM>. <NUM> in question verifies the first signature S1 <NUM> with the public key <NUM> of the sending validator node <NUM>.

The validator node <NUM>. <NUM> in question verifies the second signature S2 <NUM> with the public key of the authorised signer <NUM> as registered on the blockchain.

The validator node <NUM>. <NUM> in question stores a mapping M from the unique tag <NUM>, T to the peer address <NUM>, peer@ of the sending validator node <NUM> on the blockchain, along with the optional geo-identification <NUM>, G associated with that tag <NUM>, T. Since this is a mapping, a future registration for the same unique tag <NUM>, T will overwrite the mapping record M for enabling only one validator node to be associated with the unique tag T. In an example embodiment, a plurality of mappings is allowed for one unique tag, such as two or five. In this case, new mappings may overwrite oldest mappings on meeting a mapping limit for one unique tag. In an example embodiment, one physical line is multiplexed for two or more users. Let us assume that each user has a separate subscription from the operator and their subscription lines are separated to their own wall sockets. Now, with one unique tag for one physical line, different users could lose their validator nodes to other users sharing the same physical line. In this example embodiment, the unique tag is defined further using a subscriber identifier or a sub-port identifier. Then, each user is assigned one unique tag that can be used as if the user had a dedicated physical line. In an alternative example embodiment, no new registration is allowed for the unique tag <NUM>, T.

<FIG> shows a signalling chart of a method of an example embodiment, illustrating following events:.

<FIG> shows a signalling chart of a method of another example embodiment. This method corresponds to that of <FIG> by events <NUM> to <NUM> so these are not drawn.

The PoO logic sends the announce message as described with reference to <FIG>. In the embodiment of <FIG>, the CPE operates as the authorised signer. For example, the CPE comprises a trusted execution environment in which the CPE stores a copy of the public and private keys and in which the CPE computes the second signature. In another example embodiment illustrated by <FIG>, the CPE requests access point to generate the PoO attestation by a PoO attestation request <NUM>.

In a yet further example embodiment, the PoO attestation is generated in two phases so that first the PoO logic of the CPE produces a third cryptographic signature. Subsequently, the core network of the fixed line operator, e.g., the access point, verifies the third cryptographic signature replaces that with the second cryptographic signature, if the third cryptographic signature was correct. The PoO logic may redirect an intermediate form of the attestation signed by the third cryptographic signature to the access point or other entity in the access network or core network of the operator for the generation of the final form of the attestation with the second cryptographic signature. By using the intermediate cryptographic signing with the third cryptographic signature, each CPE may use individual public/private key pairs and still the attestations provided to the PoO blockchain can appear to originate from one or few authorised signers.

At each blockchain epoch identified as the duration to generate a configured number of blocks, a new random consensus group is elected. Each successfully registered validator node <NUM>. <NUM> is given an equal likelihood of being elected. In an example embodiment, a minimal geographical distribution or focus is used as an additional constraint in electing members of the consensus group.

Fixed communication line operators, or internet service providers are generally considered as trusted parties that:.

In an example embodiment, a set of authorised operators is registered on blockchain, or in a chain variable. There is only a very limited number of such authorised operators: one for each publicly known fixed line communication operator in the market. Adding a new authorised operator on the blockchain requires a majority vote from the blockchain peers.

In an example embodiment, the PoO blockchain requires an operator to stake tokens, which they would lose if anyone can prove dishonest behaviour. In an example embodiment, the dishonest operator is banned from further participation. In an example embodiment, the peers are enabled to promote temporary or permanent banning of a dishonest peer in which case peers of the blockchain vote regarding such a ban, and the voting result is automatically effected by the PoO blockchain.

In an example embodiment, a network of assertion enabled peers (e.g., CPEs with dedicated logic) continually assert an approximate location of other peers. In an example embodiment, the assertion enabled peers assert the approximate location of each other through a system of challenge-response interactions, measuring the latency, gathering traceroute information, etc. When deviations are detected between the approximate location (or other information, such as an IP address of a peer and IP address ranges allocated to respective operator) and the location purported in the attestation, it can be determined that the operator fails to validate its users as required by the PoO blockchain.

In an example embodiment, the CPE supplements messages to the PoO blockchain peers with PoO attestations, while another network entity of the operator generates and delivers the PoO attestations for the CPEs. Other implementations are also possible, such as that the CPE further generates the PoO attestations.

<FIG> shows a block diagram of an apparatus <NUM> according to an embodiment.

The apparatus <NUM> comprises a memory <NUM> including a persistent computer program code <NUM>. The apparatus <NUM> further comprises a processor <NUM> for controlling the operation of the apparatus <NUM> using the computer program code <NUM>, a communication unit <NUM> for communicating with other nodes. The communication unit <NUM> comprises, for example, a local area network (LAN) port; a wireless local area network (WLAN) unit; Bluetooth unit; cellular data communication unit; or satellite data communication unit. The processor <NUM> comprises, for example, any one or more of: a master control unit (MCU); a microprocessor; a digital signal processor (DSP); an application specific integrated circuit (ASIC); a field programmable gate array; and a microcontroller.

<FIG> shows a flow chart of a method for validating a new validator for a PoO blockchain, the method comprising one or more of the following steps:.

<FIG> shows a flow chart of a method for announcing the new validator to the PoO blockchain, the method comprising one or more of the following steps:.

<FIG> shows a flow chart of a method for registering a user device as a new validator to the PoO blockchain, the method comprising one or more of the following steps:.

Without in any way limiting the scope, interpretation, or application of the claims appearing below, a technical effect of one or more of the example embodiments disclosed herein is that blockchain proof can be validated based on a limited and verifiable resource that does not require any proof of work related computational mining. Another technical effect of one or more of the example embodiments disclosed herein is that the blockchain proof can be arranged without financial discrimination between different peers. Yet another technical effect of one or more of the example embodiments disclosed herein is that the blockchain proof can be effectively and verifiably geographically distributed. Embodiments may be implemented in software, hardware, application logic or a combination of software, hardware, and application logic. In an example embodiment, the application logic, software, or an instruction set is maintained on any one of various conventional computer-readable media. In the context of this document, a "computer-readable medium" may be any non-transitory media or means that can contain, store, communicate, propagate, or transport the instructions for use by or in connection with an instruction execution system, apparatus, or device, such as a computer, with one example of a computer described and depicted in <FIG>. A computer-readable medium may comprise a computer-readable storage medium that may be any media or means that can contain or store the instructions for use by or in connection with an instruction execution system, apparatus, or device, such as a computer.

Although various aspects are set out in the independent claims, other aspects comprise other combinations of features from the described embodiments and/or the dependent claims with the features of the independent claims, and not solely the combinations explicitly set out in the claims.

Claim 1:
A method for validating a new validator for a proof-of-origin, PoO, blockchain comprising
receiving (<NUM>)
an announce message comprising: a unique tag that uniquely identifies one fixed communication line of a subscriber of a fixed communication operator; a peer identifier of the new validator; an identifier of an authorised signer, and a cryptographic signature of the authorised signer over at least the unique tag, and the peer identifier;
verifying (<NUM>) validity of the announce message;
the verifying comprising checking (<NUM>) from the PoO blockchain that the authorised signer is registered on the PoO blockchain as an authorised signer; and
the verifying comprising checking (<NUM>) the cryptographic signature of the authorised signer in the announce message;
if each checking of the verifying is positive, then accepting (<NUM>) the new validator for the PoO blockchain and mapping in the PoO blockchain the unique tag with at least the peer identifier, otherwise refusing the new validator.